Yes! And exceptions and inheritance and RTTI too. Bring back all the mistakes! Let's party like it's c++99

please no

In critical low-level code, any kind of overloading - operator or otherwise - is something you'd rather not have.

By expressivity I don't mean conrecte syntax, but the number of lines needed to express an algorithm (up to a small constant). C doesn't have C++'s expressivity because it lacks templates, and while you can sort of express that kind of thing with macros, it's not all the way there. Zig, however, gets you all the way (you might need to write matrix_plus instead of +, but the expressivity is the same).

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.

Many people are against operator overloading, imo my only issue with C++ operator overloading is that you're allowed to overload the the assignment operator. From what I can see this is the root of many issues

overloading the comma is also a special flavor. everyone should try it once.

I’ve also experienced some unnecessary shenanigans related to blurring the distinction between primitive operations, and stuff that happens dynamically at run time such as method calls.

For a somewhat different example of the same general idea, look at how Java handles primitives and their boxed counterparts. = on two ints always compares their value. = on two Integers compares their pointers. But it uses flyweight instances for values up to 256, so in Java, whether two Integers with the same numeric value are equal according to the = operator depends on what that value is.

Then throw autoboxing and generics into the mix, and it suddenly becomes very easy to do refactorings that work fine in the unit tests (which tend to use small numbers) but fails in confusing ways in production.

This isn’t an example of operator overloading, of course. But I hope it more simply illustrates why, at least in certain problem domains, there’s value in being able to visually tell when surprising runtime shenanigans are and are not possible. And also to make it impossible to cross that boundary without touching all code that falls within the blast radius of that change.

> But it uses flyweight instances for values up to 256, so in Java, whether two Integers with the same numeric value are equal according to the = operator depends on what that value is. ...

I believe Java caches Integer objects for values -128..+128, not 256. But that may be an implementation detail, and not something to count on.

And since java 28's value types, == will work identically for all Integers, finally.

[delayed]

No, you’re right. I misremembered.

> No, you’re right. I misremembered.

We both misremembered. I found where this is documented and the range is -128..127 inclusive: <https://docs.oracle.com/en/java/javase/27/docs/api/java.base...>

Is there a way to support varying the meaning of "+" etc without introducing a lot of complexity? I suppose if Zig had nested functions, and the ability to define a nested function called "+", then you would have name shadowing instead of "overloading".