C++ overloaded operators are so cringe. They think they're being so clever with their pipes and the path concatenation being a "/" character but you're just making one of the most ugly languages on the market even uglier. Fuck C++ and its operator overloading fetish.

As opposed to... What? Python? Yup, same. JS? That's a dumpster fire. TS? You mean JS with type suggestions pretending to be type safety? Rust? Oh hey look, operator overloading.

Sounds like a skill issue.

@atheist It is a design error because when used extensively such as in c++, you cannot predict when to use an operator vs using a function. You usually need to actually reference the docs instead of being able to intuit your next move. They should be allowed exclusively to avoid turning into a Java with “String.equals”. C# is a great middle ground where it uses them sensibly to do things like date operations. I have never written any code and thought “hmm, an operator would be a great way to accomplish this task”

@AlgoRythm are you talking about the STL, open source library code, company code or your code?

I don't think the STL abuses it. I think the / for path handling is a really intuitive feature cuz it's the same as Linux, it looks like what it's doing. Ranges pushes it a bit, but even then... It's piping stuff. It's similar syntax to bash.

But I think the bigger problem is you're in the mindset that the operators have fixed meaning and they just... Don't in a lot of languages.

@atheist operators are mostly universal, I’m not sure what drugs you’re on. Suddenly having the division operator EITHER mean “division” or “path concatenation” depending on the context or the single pipe meaning “bitwise or” or “pipe” based on even less obvious context is an enormous detriment to the scan-ability of code and even if you’re reading it thoroughly can be confusing if you aren’t intimately familiar with what’s going on. C++ is one of the most unfriendly languages to learn and use and this is a contributing factor for absolutely sure. No doubt.

@AlgoRythm so, operators should be constrained to numbers? That's the only context where they have a fully defined relatively consistent meaning. Lists and strings, addition is concatenation, multiplication is repetition. Exponentiation or xor? Bitwise or, or set union? Oh, wait...

You're used to your specific meaning in your preferred language. AKA...

Skill issue.

@atheist maybe. But I’ve used a wide range of languages and had many favorites. C++ was never one of them. If you don’t think c++ is a jungle of poor design decisions, I think that’s an opinion issue.

I will say that I tend towards simplicity in languages. Lua and Zig have been the two I’ve been most passionate about in the past.

Operator overloading is nice when you need it. I think one place I have used it consistently is in comparison functions for sorting algorithms. I will have to look up why I needed this as I cannot remember off the top of my head.

Changing the meaning of an operator is kinda sus though. My sense of order says the operation should be remotely similar to the original operator meaning. Is it at least bounded by namespace?

What about operator chaining?

object.func().func2().func3() or some shit

@AlgoRythm "you cannot predict when to use an operator vs using a function" - you can, if you don't suck at your job.

@Demolishun chaining actually is nice and you're not fucking up default behavior you would have used else.

In my opinion the implementation of operator overloading is nicely done but agree with @AlgoRythm that's it just not a nice thing to do. Coworkers would be debugging for ages on certain code. Most people don't expect (KINDA skill issue). Bit codebase dependent. It prolly has an unwritten rule for that.

I also don't use operator overloading in exception of python __cmp__(self, other) what overloads ==

Operators are shorthands for function calls. If you couldn't describe what two functions do with the same meaningful abstract sentence, they shouldn't be represented by the same operator.

It honestly feels like Bjarne wanted a fun demo to showcase implicit casts and operator overloading so he wrote Hello World with pipes and it got so popular that he couldn't remove it afterwards.

When I was a beginner, I had this same great idea to overload the / operator for path concatenation. I felt so clever 😆.

But even as a beginner, I quickly realized my mistake and stopped this kind of bullshit.

Operator overloading is still great for things like vector arithmetics!
Have you ever used vectors in a language which doesn’t have operator overloading? Like Java? It’s a lot of fun!

@tosensei legend

@tosensei sometimes the tool is the problem.

@AlgoRythm sometimes you're the tool
🔥🚿🚒

@AlgoRythm yeah - but not in this case.

@AlgoRythm I don't know how this could possibly be a tool problem. It's not like C++ requires operator overloading for anything; if you can't judge whether to overload an operator, just don't do it. In the worst case your code will be less aesthetically pleasing, but never significantly less readable or even slightly less powerful.

@retoor operator overloading is usually new type specific (or should be). Not generic type. Generic type would have a lot of pitfalls. So for a sort you are comparing a class or struct. So you need a comparison operator to determine what value(s) in this new type you want to compare. Not change the comparison for int or float. So this can be abused, yes.

@AlgoRythm the tool, or the tool using the tool? ;-)