> The point is, it’s a tradeoff. If it's a trade off it's highly squewed.

>But you can also argue that letting the choice of function be implicit means that a programmer who wants/needs to keep track of exactly what every line of code is doing

Use LSP/IDE then ctrl+click operator. Boom. You see what it's executing.

Idea is to create abstraction that make it easier to operate on a more complex level. If you need that level of micro-managing just stick to assembly.

▲

pron a day ago | parent [-]

Neither operators nor overloading are abstractions, and they offer no operation at a higher level. An abstraction is something that creates an equivalence class among multiple implementations, and that's not the case here.

First, operators are clearly not an abstraction because they offer a 1-1 correspondence: Instead of `x + y` you write `plus(x, y)`. It's just a different notation.

Overloading also isn't an abstraction because, as you pointed out, the resolution is statically known, and again, there's a 1-1 relationship. Indeed, it's just name mangling. Instead of writing `plus_int_int(x, y)` you write `plus(x,y)` and the compiler adds the `int_int` for you.

There's no doubt operators and/or overloading have some convenience advantages, but there's also no doubt they have some disadvantages, which is why some languages disallow one or both, regardless of how high or low-level they are. But Zig also has some special reasons to prevent overloading, because the language is built around compile-time introspection. So you can have just a single `plus` for multiple types, but the static dispatch is explicitly controlled by the implementation of `plus`. This means that all resolution is always local or uses unique names.

I'm not saying you have to personally like it. Zig and Rust both aim at different preferences so that people may prefer one over the other. But there is no difference in expressivity (but there very much is between assembly or even C and either one of Zig or Rust). Rust, like C++, chooses to favour implicitness over explicitness, and Zig chooses the opposite. Both have pros and cons, and neither is universally superior to the other.

▲

Ygg2 a day ago | parent [-]

> Neither operators nor overloading are

Ok. Show me machine code for operator overloading. It's all abstraction. Assembly, LLIR, programming language.

Abstraction is all about collecting complexity and presenting a clearer interface.

	▲	pron a day ago \| parent [-]
		They don't add any abstraction or, if you will, they don't abstract over code that's not with operators and/or overloading. There is only ever a single correspondence. That operators don't add any expressive power is, I hope, easy to see, as they're just notation. That overloading doesn't add abstraction you can see from the fact that there is only one "implementation" of resolution at any call site (if there were more than one, then it wouldn't be static dispatch). Overloads offer shorthand, not abstraction. Another way to see what's abstraction and what's not is to think what you can change in one place in the program without changing another (because that's what abstraction offers: indifference to the different elements in the equivalence class it creates). But there is no change you can make in a program with overloads that will require fewer changes in a program without them.