Hacker News Reader

Comment by kettlecorn | Hacker News Reader

It also comes up with vector addition, subtraction, and multiplication, all of which are used all over in gameplay code.

I like Zig overall, but lack of operator-overloading just seems like a pain to me.

Zig in many ways puts faith in the coder to not screw things up, but in this case it diverges from that philosophy. Would it be too much to trust the user not to overload operators in an unacceptable way? Social convention over technical constraint.

That said I'd be more persuaded by the argument that it's not worth the extra code and complexity for a language as concise as Zig.

View on HN

> lack of operator-overloading just seems like a pain to me.

It is a pain, but all things considered, having it would have been a greater pain. Note that the main issue with operator overloading in Zig isn't so much the operator part but the overloading part, because overloading introduces ambiguity that cannot be resolved at the code-unit level. Zig doesn't allow name overloading even for ordinary identifiers (actually, Zig is more strict in its opposition to overloading than Clojure or Erlang, which do allow it when there can be no ambiguity). I think it's more likely that Zig will allow user-defined infix operators (say +' or something) before it allows overloading of any kind.

> Zig in many ways puts faith in the coder to not screw things up

I understand Zig very differently. Zig puts a lot of effort to make it hard for the coder to screw up. Even where it doesn't enforce correctness at compile time or at runtime (and it does both much more than C++, to the point that the goal is to eliminate all or nearly all undefined behaviour in safe mode), its strong emphasis on correctness, including functional correctness, is expressed precisely through a simple and lean language that's easy to understand, so that it's harder for the programmer to screw up (plus fast compilation and easily isolated code units). So to the extent that Zig puts faith in the coder (less than C++, more than Rust), it can do so because the language is so lean and simple.

> I think it's more likely that Zig will allow user-defined infix operators (say +' or something) before it allows overloading of any kind.

I proposed this and it got rejected by the language committee.

I meant that they'd sooner allow some infix operators than overloading, not that they intend to add operators in the language's first version.

> because overloading introduces ambiguity that cannot be resolved at the code-unit level

Can you explain this a bit? Operator overloading just seems like such a strange bugbear of Zig folks to me. Maybe I've just never been bitten by it, but at least in Elixir, my main language, I've never really understood the danger.

Are operators truly so different from functions? You'd expect that any function you import could do, well, anything. Aren't operators essentially just the same thing, just with a "prelude" in the language that basically imports them by default?

In Elixir, you might have (discouraged):

    defmodule MyMod do
      import MyOperators

and then you know to check what's defined by MyOperators, for that module. But more common, if you really wanted to overload, would be to be more specific:

    defmodule MyMod do
      import MyOps, only: [+: 2]

and then you know plus (with two arguments) has a different meaning in that module.

I’m not super familiar with Zig specifically, aside from watching some of Andrew’s talks and coding streams. But this thought process is not a Zig only concept. As far as I know, the explicit ‘operators’ that are provided with Zig are guaranteed to be a low-level construct (ideally implemented at the ISA level) which are made visible to users of the language in standard ways, i.e. infix arithmetic operators. When overloading of these operators is allowable that guarantee goes out the window. There is a fundamental difference at the generated code level between a function call resulting from a use of ‘’ to multiple two random matrices and a use of ‘’ to multiple two 32 but integers. Further, as I understand it, Zig guarantees that anything that allocates memory does so explicitly and anything that calls a function does so explicitly. The very concept of operator overloading is incompatible with such a guarantee. So, I think given the implied goal of explicit is better, it makes sense that a flat rejection of operator overloading is the broad view.

So zig doesn't support 64bit arithmetics on 32/16/8bit architectures? What about division? Quite a few hardware don't support division( https://community.arm.com/developer/ip-products/processors/b...).

> The very concept of operator overloading is incompatible with such a guarantee.

Why would operator overloading allocate memory? The memory is already allocated(by the user) when you call with the operands.

> Why would operator overloading allocate memory?

What if I wanted to overload the + operator to concatenate strings?

Yes that was poorly thought out. I realized it after i commented.

There is definitely some merit in being puritanical about not having any allocations in operators.

> Operator overloading just seems like such a strange bugbear of Zig folks to me.

Not operator overloading; just overloading. You can't overload ordinary-named subroutines in Zig either.

> and then you know plus (with two arguments) has a different meaning in that module.

That's not overloading, that's shadowing. Overloading is when the same name refers to multiple things depending on the type of its arguments. Erlang allows overloading based on arity, but that's something that can be understood from the call-site code.

> overloading introduces ambiguity that cannot be resolved at the code-unit level

This seems clearly false to me. Operator overloading is non-virtual type-based dispatch, just like the dot operator for method calls in C++/Java/etc., and is resolved statically at compile time. You can think of overloadable "+" as just syntactic sugar for an ".add()" method (in fact, this is more or less exactly how it's implemented in Rust). Even if your language doesn't have methods, you can implement overloading with typeclasses, like Haskell does (as does Rust, formally speaking).

Operators are a red herring here; what Zig disallows is overloading of names, period. Yes, overloading is resolved statically at compile time, but that's not the point (Zig does allow dynamic dispatch). The point is that a simple understanding of what the code does requires information available outside the unit (subroutine or even file). A subroutine can contain two references to `foo` resolving to two different targets, but you can't know that from the code in the subroutine. The meaning of a name must be defined in one place in Zig, and a name can only refer to one thing.

We could certainly argue on whether disallowing overloading is helpful, but it's first important to understand what the principle is, and it's not about the operators.

> The point is that a simple understanding of what the code does requires information available outside the unit (subroutine or even file).

No, it doesn't. Knowing what function "+" resolves to requires only the type of the left-hand side (or, I think, the RHS as well in Haskell). Absent overlapping instances (which Rust doesn't support, and Haskell only supports with an extension), there can only be one such function implementation per type. And, since top-level items are fully type-annotated in Rust (and idiomatically annotated in Haskell), this is a completely local determination. Therefore, for every occurrence of "+" in the source, it's completely unambiguous which implementation "+" calls, and this can be determined solely by looking at the calling function.

The end result: Rust, like Zig, disallows overloading of names, but Rust also effectively supports overloaded operators via traits (typeclasses).

> there can only be one such function implementation per type

Right, and that's more than one definition per name. In Zig, a name refers to only one definition. (Plus, recall that in Zig the type of a target isn't always known when reading the code, probably more frequently than in C++ or Rust, where this only happens in macros.)

> disallows overloading of names

That the definition referred to by an identifier depends on the type is what overloading means. Overloading is the very essence of traits.

P.S.

> in C++ or Rust, where this only happens in macros

Sorry, this is wrong. In both of these languages it happens much more frequently. All the time, in fact, whenever you either infer return types or just chain calls on return values, or when the type is a generic/template type parameter. So when you see `foo(e)` or `e.foo()`, where `e` is some expression, you can only tell which definition of `foo` is referenced -- or even whether two instances of `foo` refer to the same definition or not -- by figuring out the type of `e`, which is often implicit in the code.

> Overloading is the very essence of traits.

Which is why in Zig, the mechanisms that perform a similar task to that of traits -- i.e. abstracting over types -- work differently, without overloading.

As a general rule, Zig does not want the semantics of a piece of code to depend on things the compiler might know but the reader of the unit might not. Whether or not such a degree of explicitness is a worthy principle for a low-level language is a matter of taste, I suppose.

IMHO better than operator overloading (which opens the gates to hell) would be builtin vector and matrix types like in shading languages. Currently Zig has a vector type builtin (search for @Vector and/or std.meta.Vector), which supports the "simple" operations (addition, subtraction etc...), so it's halfway there, but no swizzle, and no matrix types.

The @Vector provided is actually a reference to SIMD vectors and there has been discussion to rename it to something that reflects this more clearly.

https://github.com/ziglang/zig/issues/7305

I would love to see Clang's ext_vector_type extension features in Zig, it lets you write code like GLSL, including easy swizzling. Add the same thing for matrix types, and the the feature would be complete, no need for operator overloading:

https://www.godbolt.org/z/zWGfcY5a4

Whether this code translates to SIMD or scalar operations under the hood should depend on the target platform and compiler options.

Would it be possible to do a slight Zig fork that works a bit like Rust, where + calls the add(), - the sub(), and * the mul() designed specifically for cases that needs it? Or maybe do it by declaring something at the top of your file? That could be a good compromise.

I did this, but the code underneath changed on me with the self-hosted compiler... it's not hard if you really wanted to. (~200 LOC)

Reply on news.ycombinator.com