5 ms·

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls,

The problem with operator overloading is not really numericity, IMO. The problems are: - hidden control flow (function calls should look like function calls, an operation should never mask a function call) - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes?

spc476 3y ago
Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.
- throwawaymaths 3y ago
  You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
  - kps 3y ago
    Multiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r22 16: 00 f0 brcs .+0 18: 71 05 cpc r23, r1 1a: 01 f4 brne .+0 1c: 80 2d mov r24, r0 1e: 95 2f mov r25, r21 20: 08 95 ret
    - throwawaymaths 3y ago
      I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.
  - pornel 3y ago
    Not always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.
  - deleted 3y ago
    [deleted]
saagarjha 3y ago
Your atomic increment may turn into a function call if it’s targeting multiple microarchitectures.
avgcorrection 3y ago
> hidden control flow (function calls should look like function calls, an operation should never mask a function call) An operator is either a function call or some simple built-in operation. Thus not hidden. That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.
- Mawr 3y ago
  > An operator is either a function call or some simple built-in operation. In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is. It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice. Humans just don't work like that.
  - avgcorrection 3y ago
    > In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is. Noo it isn’t. Many languages use something like `+` for string concatenation. Maybe list concatenation.
naasking 3y ago
> - hidden control flow (function calls should look like function calls, an operation should never mask a function call) You can restrict operator definitions to expressions containing other operators. Operators are now guaranteed to expose only as much control flow as the underlying operators would already expose. > - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes? I'm not sure what you mean. Behaviour depends on language semantics. You don't specify why operators are uniquely weird on this compared to literally any other function call when language semantics or library behaviour changes.

spc476 3y ago

Some CPUs don't have a MUL or (like some 32-bit RISC architectures) DIV instruction, and on these, the C compile has to fall back to a function call.

throwawaymaths 3y ago
You sure the compiler doesn't inline it? That an operator might take more than one opcode I think is uncontroversial
- kps 3y ago
  Multiplication takes more than a handful of instructions if the hardware doesn't do it. https://godbolt.org/z/ccYPaz1Pj https://godbolt.org/z/ccYPaz1Pj For this example (AVR), this is the int multiply function __mulhi3: 00: 00 24 eor r0, r0 02: 55 27 eor r21, r21 04: 00 c0 rjmp .+0 06: 08 0e add r0, r24 08: 59 1f adc r21, r25 0a: 88 0f add r24, r24 0c: 99 1f adc r25, r25 0e: 00 97 sbiw r24, 0x00 10: 01 f0 breq .+0 12: 76 95 lsr r23 14: 67 95 ror r22 16: 00 f0 brcs .+0 18: 71 05 cpc r23, r1 1a: 01 f4 brne .+0 1c: 80 2d mov r24, r0 1e: 95 2f mov r25, r21 20: 08 95 ret
  - throwawaymaths 3y ago
    I mean, pedantically speaking the normal zig operators do control flow in their operators, in checked mode they panic on overflow, etc (you're not supposed to recover from them but I suppose it's possible). There's probably (internal) control flow in the saturating operators, etc.
- pornel 3y ago
  Not always. I’ve seen division and atomic operations stay as function calls to libgcc. However, semantics of these are well-defined either way, unlike user-defined operators, so existence of a hidden call is at most an inconvenience when linking code from different compilers.
- deleted 3y ago
  [deleted]

saagarjha 3y ago

Your atomic increment may turn into a function call if it’s targeting multiple microarchitectures.

avgcorrection 3y ago

> hidden control flow (function calls should look like function calls, an operation should never mask a function call) An operator is either a function call or some simple built-in operation. Thus not hidden. That syntactic elements that consist of symbols rather than alnum and that are used as prefix or infix operators are necessarily “not a function call” is just a rule that can be changed.

Mawr 3y ago
> An operator is either a function call or some simple built-in operation. In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is. It's like a self-driving car that's safe 99.999% of the time but still requires you to continuously pay attention to take over at a second's notice. Humans just don't work like that.
- avgcorrection 3y ago
  > In theory, yes. In practice, an operator is a simple built-in operation 99.999% of the time, which lures programmers into thinking that's how it always is. Noo it isn’t. Many languages use something like `+` for string concatenation. Maybe list concatenation.

naasking 3y ago

> - hidden control flow (function calls should look like function calls, an operation should never mask a function call) You can restrict operator definitions to expressions containing other operators. Operators are now guaranteed to expose only as much control flow as the underlying operators would already expose. > - global weirdness. If a library changes the language, how does that affect some other code you're pulling in? Where do you effect those changes? I'm not sure what you mean. Behaviour depends on language semantics. You don't specify why operators are uniquely weird on this compared to literally any other function call when language semantics or library behaviour changes.