This is the type of shit that haunts me. Imagine overloading “>>” for piping and hiding threading behind that. The idea was to create an async pipe, but nowhere are you aware of async or threading or whatever was chosen. You look at the code and think “of it’s like piping to stdout” or whatever, only to find out that the method immediately returns.

Tracking down what the hell is happening with code that has such hidden side effects is a nightmare.

Are you still in the C++ world?

Like all of the footguns in C++, it’s only a problem if the codebase uses it wrong. When used correctly (i.e. only when behaviours mimic built-in types, and without side effects), it helps makes code more readable

Don’t do what numpy does, which is to define * for two arrays. Without learning the library, you wouldn’t know whether this performs element-wise multiplication, matrix multiplication, dot product or cross product. Worse yet, it behaves differently to Python’s built-in * for lists (which is also bad), which concatenates N copies of the list

Clearly you’ve never had to read code like

entity.position = vector_algebra::vector2_add(entity.position, vector_algebra::vector2_scale(entity.velocity, dt));

Every time I use a language that doesn’t have operator overloading I wish I was using C++. It’s absolutely maddening to have to read and write things like “end.subtract(start)”.

Operator overloading is awesome in a functional language. Haskell allows for a lot of creative stuff with operators, but since they can’t have side effects, must conform to predictable types, and have specific requirements they are somewhat understandable. Idris is also very ergonomic when it comes to operators.

C++ allowing a library to override the + operator with system("rm -rf /") is a lot less awesome.

As a computational physicist, I appreciate operator overloading IF used properly.
Example of a good use: + for matrix addition
Example of a bad use: left shift operator << as a pipe
I still don’t understand who’s in the C++ committee that they would choose this garbage over a function

Honestly, I’m glad to have them, it can make a number of things simpler. For instance, a program I wrote had a number of duration fields that had to be stored in XML files and updated every once in a while. It was something that had to occur very often in the code: add a value to the duration, set that value in the XML data, and save the XML file. So I created a class that stored the date/time value and a pointer the XML element (it could be assumed that nothing else would be changing the value in the XML file and if it did, then that change should be overwritten) and overloaded the += operator (among others), so then all I needed was to create the DurationField object, and then I could go durationFieldX += time2 - time1 for instance. I could abstract all the logic away and make it very clear and easy to write. Could I have made it so that I have to to durationFieldX.add(time2 - time1)? Of course I could have. But IMO that variant is less neat and less readable.

People have made NULL to be a random number on a specific day. As a goodbye present :D

I always enjoy this one: https://crates.io/crates/inline-python

Apparently, Python’s syntax is almost entirely a subset of Rust’s syntax + a few keywords, so even though you have to pass valid Rust tokens into a macro, that’s good enough to write Python with just a few quirks.

That’s inside the macro though. Whatever you parse inside the macro is defined by the creator of the macro. The macro invocation itself is defined by the rust language.

Rust allows you to use any bracket because it doesn’t know what the macro is supposed to do.

Some macros work like functions:

println!("Hello world");

Some macros work like array declarations:

let v = vec![1,2,3];

And some macros work like a code scope:

select!{
 a => myfunc(),
 b => my_other_func()
}

Since rust doesn’t know what your macro does, it just lets the user choose whatever the user sees more fitting for that specific macro invocation.

Yeah, I always wonder, if it was an intentional decision or just some first draft that stayed in.

Because I do think, it’s kind of smart. Some macros make sense to call with either () or {}, depending on if you pass a code snippet that’s multi-line or not.
So, you could come up with a complicated syntax to define which bracket types are acceptable, or you could just not bother. 🙃

If Wikipedia is to be believed English (at least British English) does in fact the same thing. Although it’s “curly” instead of “curved” brackets.

In example code, yes, but in this meme specifically which is all about function call syntax, it ruins the point. E.g. every line in the C++ snippet includes parentheses.

Ah, that’s why… I didn’t think multiple arguments to operator[] was valid, but my brain is still catching up to C++20 features.