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.

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

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.

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.