C++ destroyed the good will here by simultaneously insisting that you're only supposed to use this feature to give types their natural operators (makes sense) and then inventing implausible new "natural" operators so that Bjarne can show off his new toy with the I/O streams.

I actually don't like Rust's choice to implement + for Strings but most people seem to accept that, however C++ goes ludicrously far beyond "I don't like it but some people do" and straight off the cliff into "Nobody thinks that's OK" leaving you to wonder why there was effort to implement this bad idea. For example C++ can overload the short-circuiting boolean operators... but the overloaded versions don't short circuit. So now you've made things dramatically worse!

▲ pron 2 days ago | parent [-]

Note that it's not that Zig is opposed to (user-controlled) operator overloading; it's opposed to (user-controlled) overloading of all symbols: The resolution of `foo` in `foo(x)` should not depend on the type of `x`. The issue is not the operators but the overloading, and Zig wants to prevent (user-controlled) overloading of any kind. This makes some things less convenient and other things more convenient.

▲ tialaramex 2 days ago | parent [-]

> The resolution of `foo` in `foo(x)` should not depend on the type of `x`

This depends on how you're squinting at this word "resolution".

Remember on a modern CPU an XOR R1 R1 does not result in an ALU operation, the decoder understands this idiom and just renames a zero'd register as R1, whereas of course it can't do that for say XOR R2 R3 because that's an actual XOR operation. So if "resolution" means "exactly what happens on the CPU" apparently there is no such facility provided even in assembler.

So apparently we mean only that it should have, in some sense, the same effect. I think the fact Rust is OK with

  assert!("Goose".contains('o'))
  assert!("Goose".contains("Goo"))
  assert!("Goose".contains(&['a', 'e', 'i', 'o', 'u']))

.. meets this criterion, whereas presumably you do not agree.

	▲	pron 2 days ago \| parent [-]
		It's not about okay or not okay. Zig is designed to prevent any user code from being implicitly called, or for the resolution of user code to be done implicitly. It's not about what the CPU does internally, but whether you're able to tell, from reading the code of a single subroutine, which operations could be done, whether stack frames can be created etc.. This has pros and cons, and for some people the pros outweigh the cons and for others, the other way around, and that's why different programming languages need to prioritise different things when they target different users. Just as Rust clearly isn't supposed to be best for all uses, neither is Zig, or any other language for that matter. Every language is meant to appeal to some and not others.