5 ms·

> 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

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

throwaway17_17 5y ago
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.
- xfer 5y ago
  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/processors-ip-blog/posts/divide-and-conquer 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.
  - dinglejungle 5y ago
    > Why would operator overloading allocate memory? What if I wanted to overload the + operator to concatenate strings?
    - xfer 5y ago
      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.
pron 5y ago
> 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.

throwaway17_17 5y ago

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.

xfer 5y ago
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/processors-ip-blog/posts/divide-and-conquer 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.
- dinglejungle 5y ago
  > Why would operator overloading allocate memory? What if I wanted to overload the + operator to concatenate strings?
  - xfer 5y ago
    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.

pron 5y ago

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