BS. Using operator overloading with SIMD makes it easier to translate algorithms into code. I wrote my own U8x32 wrappers and a + b is way better than a.add(b).

I'm not disputing that some people like operator overloading, but clearly others prefer no overloading of any kind (don't know what the LLMs prefer, if they have any preferences). That's why we need options.

[delayed]

I'm not talking about custom operators. I'm talking about the ability for programs to overload either operators or other symbols (subroutine names). It's true that custom operators don't have to support overloads, but it's hard not to get collisions without overloads.

You can do a+b in Zig with SIMD vectors. No operator overloading required

Sure. But doesn't it still lack autodiff, quaternions, etc?

Yes, there are definitely other use cases that Zig doesn't support (which some may view as a good or bad thing). I just wanted to respond to the comment about basic SIMD since the example was U8x32 and operator+, which Zig can do.

Point wasn't about SIMD, but defining my wrapper for it and giving it operations I needed.

Which seems to be something Zig can't do.

Hell, you can define operators for generic length SIMD lane.

Same goes for any bitwise operation <<, >>, &, |, %.

Can I write my SIMD/number abstraction and have it work?

Let's say I need rotors. With six dimensions. Can I overload it's basic numeric operations?

The example you choose is rather telling, though. It indicates that the use case you have in mind is not at all the one that Zig is targeting.

A more humble critique would be to just acknowledge that you don’t seem to be a member of Zig’s target audience, and move on.

I am in the target audience. I do want low level systems programming.

Saying "you don't want operator overloading" in such cases is a reductionist view of how systems programming should look.

To be fair, the impression is that you want to do low level systems programming in Rust. It's a fine preference but it does put you in a different audience

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!

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.

> 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.

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.