Hacker News Reader

Comment by skocznymroczny | Hacker News Reader

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.

View on HN

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.

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

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.

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.

I don't know about PHP, what amount of magic goes in behind Python's dunder methods? You can open it and see

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

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.

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

[2] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...

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.

There is a specialized `@Vector` builtin for SIMD operations like this.

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.

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.

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.

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)()`.)

or 'plus' could be a macro...

Reply on news.ycombinator.com