4 ms·

Zig looks interesting, I just wish it had operator overloading. I don't really buy most of the arguments against operator overloading. A common argument is that

Zig looks interesting, I just wish it had operator overloading. I don't really buy most of the arguments against operator overloading. A common argument is that with operator overloading you don't know what actually happens under the hood. Which doesn't work, because you might as well create a function named "add" which does multiplication. Another argument is iostreams in C++ or boost::spirit as examples of operator overloading abuse. But I haven't really seen that happen in other languages that have operator overloading, it seems to be C++ specific.

flohofwoe 2y ago
In C++ I ever only used operator overloading for vector/matrix math (where it is indeed very useful). I'd be fine if a language implements the vector math syntax directly (like shading languages do). Zig at least has a @Vector() [1] type which is a bit similar to Clang's Vector Extension (but unfortunately not the Extended Vector Extension) [2]. [1] https://ziglang.org/documentation/master/#Vector https://ziglang.org/documentation/master/#Vector [2] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...
hiccuphippo 2y ago
You don't know the amout of magic that goes behind the scenes in python and php with the __ functions. I think zig's approach is refreshing. Being able to follow the code trumps the seconds wasted typing the extra code.
- magicalhippo 2y ago
  Depends on domain I think. In some cases it can be very beneficial to keep the code close to the source, say math equations, to ensure they've been correctly implemented. In this case the operators should be unsurprising, so they do what one would expect based on the source domain. Multiplying a vector and a scalar for example should return the scaled vector, but one should most likely not implement multiplication between vectors as that would likely cause confusion.
- melodyogonna 2y ago
  I don't know about PHP, what amount of magic goes in behind Python's dunder methods? You can open it and see
  - akkad33 2y ago
    There are many gotchas to Python dunder methods. An example is there is a bunch of functions that can be called when you do something like 's.d' where s is an object. Does it call "getattr" on the object, getattr on the class or get a property, or execute a descriptor? It is very hard to tell unless you're an expert
ptrwis 2y ago
Maybe such operators for basic linear algebra (for arrays of numbers) should be just built into the language instead of overloading operations. I'm not sure if such a proposal doesn't already exists.
- spiffyk 2y ago
  There is a specialized `@Vector` builtin for SIMD operations like this.
bigpingo 2y ago
Yeah I never got the aversion to operator overloading either. "+ can do anything!" As you said, so can plus(). "Hidden function calls?" Have they never programmed a soft float or microcontroller without a div instruction? Function calls for every floating point op.
- mk12 2y ago
  The problem is not that + calls a function. The problem is that + could call one of many different functions, i.e. it is overloaded. Zig does not allow overloading plus() based on the argument types. When you see plus(), you know there is exactly one function named “plus” in scope and it calls that.
  - kps 2y ago
    Not if `plus` is a pointer. Then `plus()` is a conditional branch where the condition can be arbitrarily far away in space (dynamically scoped) and time. That's why I think invisible indirection is a mistake. (C used to require `(*plus)()`.)
    - gpderetta 2y ago
      or 'plus' could be a macro...
  - gpderetta 2y ago
    operator + is overloaded even in plain C: it will generate different instructions for pointers, floats, integers, _Complex, _Atomic and the quasi standard __float128. Sometimes it will even generate function calls. I suspect zig might be similar.
LAC-Tech 2y ago
I feel like the ocaml solution would fit zigs usecase well. In ocaml you can redefine operators... but only in the context of another module. So if I re-define + in some module Vec3, I can do: Vec3.(a + b + c + d) Or even: let open Vec3 in a + b + c + d So there you go, no "where did the + operator come from?" questions when reading the source, and still much nicer than: a.add(b).add(c).add(d) I doubt zig will change though. The language is starting to crystallize and anything that solved this challenge would be massive.
- flohofwoe 2y ago
  For something as simple as a vec3 type, Zig has a @Vector 'meta-type', it's quite bare bones though: https://ziglang.org/documentation/master/#Vector https://ziglang.org/documentation/master/#Vector
zoogeny 2y ago
In my humble opinion, a lot of the dislike of operator overloading is related to unexpected runtime performance. My ideal solution would be for the language to introduce custom operators that clearly indicate an overload. Something like a prefix/postfix (e.g. `let c = a |+| b`). That way it is clear to the person viewing the code that the |+| operation is actually a function call. This is still open to abuse but I think it at least removes one of the major concerns.

flohofwoe 2y ago

In C++ I ever only used operator overloading for vector/matrix math (where it is indeed very useful). I'd be fine if a language implements the vector math syntax directly (like shading languages do). Zig at least has a @Vector() [1] type which is a bit similar to Clang's Vector Extension (but unfortunately not the Extended Vector Extension) [2]. [1] https://ziglang.org/documentation/master/#Vector https://ziglang.org/documentation/master/#Vector [2] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...

hiccuphippo 2y ago

You don't know the amout of magic that goes behind the scenes in python and php with the __ functions. I think zig's approach is refreshing. Being able to follow the code trumps the seconds wasted typing the extra code.

magicalhippo 2y ago
Depends on domain I think. In some cases it can be very beneficial to keep the code close to the source, say math equations, to ensure they've been correctly implemented. In this case the operators should be unsurprising, so they do what one would expect based on the source domain. Multiplying a vector and a scalar for example should return the scaled vector, but one should most likely not implement multiplication between vectors as that would likely cause confusion.
melodyogonna 2y ago
I don't know about PHP, what amount of magic goes in behind Python's dunder methods? You can open it and see
- akkad33 2y ago
  There are many gotchas to Python dunder methods. An example is there is a bunch of functions that can be called when you do something like 's.d' where s is an object. Does it call "getattr" on the object, getattr on the class or get a property, or execute a descriptor? It is very hard to tell unless you're an expert

ptrwis 2y ago

Maybe such operators for basic linear algebra (for arrays of numbers) should be just built into the language instead of overloading operations. I'm not sure if such a proposal doesn't already exists.

spiffyk 2y ago
There is a specialized `@Vector` builtin for SIMD operations like this.

bigpingo 2y ago

Yeah I never got the aversion to operator overloading either. "+ can do anything!" As you said, so can plus(). "Hidden function calls?" Have they never programmed a soft float or microcontroller without a div instruction? Function calls for every floating point op.

mk12 2y ago
The problem is not that + calls a function. The problem is that + could call one of many different functions, i.e. it is overloaded. Zig does not allow overloading plus() based on the argument types. When you see plus(), you know there is exactly one function named “plus” in scope and it calls that.
- kps 2y ago
  Not if `plus` is a pointer. Then `plus()` is a conditional branch where the condition can be arbitrarily far away in space (dynamically scoped) and time. That's why I think invisible indirection is a mistake. (C used to require `(*plus)()`.)
  - gpderetta 2y ago
    or 'plus' could be a macro...
- gpderetta 2y ago
  operator + is overloaded even in plain C: it will generate different instructions for pointers, floats, integers, _Complex, _Atomic and the quasi standard __float128. Sometimes it will even generate function calls. I suspect zig might be similar.

LAC-Tech 2y ago

I feel like the ocaml solution would fit zigs usecase well. In ocaml you can redefine operators... but only in the context of another module. So if I re-define + in some module Vec3, I can do: Vec3.(a + b + c + d) Or even: let open Vec3 in a + b + c + d So there you go, no "where did the + operator come from?" questions when reading the source, and still much nicer than: a.add(b).add(c).add(d) I doubt zig will change though. The language is starting to crystallize and anything that solved this challenge would be massive.

flohofwoe 2y ago
For something as simple as a vec3 type, Zig has a @Vector 'meta-type', it's quite bare bones though: https://ziglang.org/documentation/master/#Vector https://ziglang.org/documentation/master/#Vector

zoogeny 2y ago

In my humble opinion, a lot of the dislike of operator overloading is related to unexpected runtime performance. My ideal solution would be for the language to introduce custom operators that clearly indicate an overload. Something like a prefix/postfix (e.g. `let c = a |+| b`). That way it is clear to the person viewing the code that the |+| operation is actually a function call. This is still open to abuse but I think it at least removes one of the major concerns.