5 ms·

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 operat

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.

flohofwoe 5y ago
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.
- Hoppetosse 5y ago
  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 https://github.com/ziglang/zig/issues/7305
  - flohofwoe 5y ago
    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 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.
pron 5y ago
> 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.
- losvedir 5y ago
  > 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.
  - 5y ago
Zababa 5y ago
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.
- dnautics 5y ago
  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)

flohofwoe 5y ago

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.

Hoppetosse 5y ago
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 https://github.com/ziglang/zig/issues/7305
- flohofwoe 5y ago
  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 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.

pron 5y ago

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

losvedir 5y ago
> 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.
- 5y ago

Zababa 5y ago

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.

dnautics 5y ago
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)