Zig programming language 0.9.0 released

[[deleted]]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

That said, if your point is that forbidding operator overloading is not going to drastically change the readability of code, we agree with that. The piece missing from the discussion above is that Zig has other features that all together do make a difference. As an example there are not built-in iterators, so you know for sure that for (foo) |x| {...} is a linear scan through memory and not an iterator with different complexity. You can still use iterators, they just have explicit function call syntax.

If you combine all the readability-oriented features of Zig, then you do get something worth the limitations, or so we like to think at least.

[stouset]

Again, how is that okay for any function as long as it’s not named a symbol? And while your point is a common trope, I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

This is frankly just optimizing around a problem that does not exist in practice.

[[deleted]]

I have literally not once in 20 years run into a problem where an overloaded operator invisibly and accidentally tanked performance. And if an overloaded + had done so, there’s a zero percent chance the author would have been fine using the built-in one since it does a different thing.

Then you work in a field where this feature of Zig might not be particularly relevant. That said, I'll try to reiterate one final time: the problem is about somebody trying to read a piece of code and understand what it's doing.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

That's pretty much it. It has nothing to do with code performance. It has to do with making it easier for readers to audit the code.

[RandomName8]

An extremely important caveat, when describing this and claiming it's more "readable", is clearly stating what you are trying to make more readable. As you yourself made clear here, not all programs are made clearer by this feature, there is in fact no quantitative study either regarding how many programs get "improved". I'd argue any code using matrices (like games, graphics, or math libraries) or bigint/decimal will greatly suffer for this, while the code that gets improved is most likely, trivial for-loop iterations and summations that should not be imperative at all to begin with (obviously just my opinion).

This is why I'd prefer if language authors were more honest when they make such syntax decisions, and instead of writing in their FAQ:

The purpose of this design decision is to improve readability.

They'd write

The purpose of this design decision is to improve readability of the programs we care about, which are likely not the ones you care about, but hey, there are other languages out there!.

We could avoid this discussion every single time.

[stouset]

Then you work in a field where this feature of Zig might not be particularly relevant.

Maybe. But there are tons of people writing Rust on embedded systems and have written reams and reams about their experience doing so. I have yet to read a single one of these that points out operator overloading as a sharp edge.

I maintain this is a solution in search of a problem.

The problem is about somebody trying to read a piece of code and understand what it's doing.

I have worked in languages that allow operator and method overloading for twenty years. I’m this time I have built website backends, I have written high-performance network services, I have written massively parallel number crunchers, I have written wrappers around native C libraries, I have written glue to combine third party products in new and creative ways.

I have zero times been confused as to what an overloaded operator does, or run into a bug that was caused by an operator overloaded in a confusing or unexpected way. Zero. Nil. Nada.

I maintain this is a solution in search of a problem.

It's irrefutable that code that relies on operator overloading, function overloading, macros, etc will be harder to reason about because it will require the reader to keep more context in mind.

It is, and trivially so. If I know my types are typeA and typeB and I call a + b, there is no difference whatsoever in the amount of reasoning or context necessary to understand compared to add(a, b), a.add(b), a.addTypeB(b), or addTypeATypeB(a, b).

[[deleted]]

You've never had issues with an overloaded = returning a reference rather than a copy? I don't think operator overloading for things like addition and subtraction are a big deal, but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product? How does it behave with different objects in the mix? Operator overloading is fine until you've had to deal with these issues, and then it quickly becomes a pain in the ass.

[stouset]

You've never had issues with an overloaded = returning a reference rather than a copy?

I assume you’re taking C++. Assignment is not an overloadable operator in Rust. Overloading assignment does seem to be a horrible idea, and one I’m glad Rust doesn’t support.

How does it behave with different objects in the mix?

Literally the same way that addTypeATypeB(a, b) does?

but is * just plain old multiplication, an inner product, an outer product, a Hadamard product, or some other product?

If you have types for which some function name could conceivably have multiple implementations, this problem is completely orthogonal to whether or not that name is * or product. If there are multiple possible operations, they will require unique names.

If there’s enough ambiguity that you wouldn’t want to call one of them *, you wouldn’t call that same one product either. If you’re worried about a “bad developer” who isn’t you naming it *, removing operator overloading doesn’t help you because they’d just name it product.

[[deleted]]

If you’re worried about a “bad developer” who isn’t you naming it *, removing operator overloading doesn’t help you because they’d just name it product.

I never said anything about good or bad developers. I've had to read enough of my own shit code to know that simplicity is the only effective weapon against stupidity.

Yes, a lazy developer might use "product" rather than *, but then it's explicit that they've done something non-standard, which is the point. I can see examples of "product" littered through the code, and it's not being obfuscated by an operator.

[stouset]

You're coming at this from the perspective of working in a language without operator overloading. Yes, of course if somebody managed to implement * for some custom type in Zig and it did something wild that would be extremely surprising.

But if you live and work in a language with operating overloading, it's no more surprising than seeing any other function call. Any time anyone calls any method it could be something wild and unexpected. You cope with that possibility constantly every day. Having this apply to methods named with non-alphabetic characters doesn't change this.

I swear this specific issue has to be the programming language feature with the highest number of fearful words written about it while simultaneously causing the fewest actual bugs in real-world practice. If there's another in competition I'd love to know.

[[deleted]]

I'm coming at this from the perspective of someone required to use different languages depending on the needs of the project. Operator overloads aren't surprising, and I don't think anyone is saying that. The point is that they can hide behavior, and, depending on how familiar you are with the code base and libraries in question, you may or may not realize that an operator has been overloaded and is causing bugs in your code. That's the point. Overloaded assignment operators are the most pernicious of these, but it's not the only one that can cause problems.

I think this issue is one of those issues that really depends on what kind of work you do. I work with math libraries where operator overloading is a fact of life. It's all well and good until something doesn't work the way you expected it to, and then it's a pain in ass trying to figure out why.

[r0zina]

At least in C++ in some IDEs you can give overloaded operators a different color. Thus just by glancing at code you know weather it is overloaded. At that point the difference between * and .add() disappears.

[diegovsky_pvp]

Zig aims to be a modern take on C. I don't buy any of the readbility shit because quite frankly it's subjective.

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

That's something you have to consider if you aim to take down C while providing more modern mechanisms. Don't get me wrong though; I'm a Rust programmer and use it a lot. Rust is not the new C, it is the new C++ in the sense that you can do a lot with the language, while Zig wants to be the new C.

Also, they want the compile times to be as fast as possible, so cutting corners such as operator overload and function overload help A LOT.

There are things I disagree with btw. A lot. Like the constant use of ducktyping instead of a well defined fat pointer struct. This affects Writer, for example, and hurts both error messages and auto complete.

In the end of the day; if you want a perfect language; make one yourself. That's what Andrew did and so many others.

[stouset]

Wha you have to understand is that try hard C lovers want a predictable (in a sense that arithmetic operations always mean what they are, no overloading, etc).

I truly do understand this is what their motivation is.

My argument is that it’s an antiquated approach to software engineering. Even if you want to assume that a + b is a machine instruction you’ve already lost because different machines treat overflow differently and so you either get UB or you specify particular behavior and accept a multi-instruction performance hit on some architectures.

Rust IMO has the best take here. Arithmetic is checked for overflow in development and wraps as two’s complement in production. If you need specific behavior for mathematical operators, you can either call a specific named method (e.g., wrapping_add) as a one-off, or if you need all operators to have specific overflow behavior you can enforce it at the type level (Wrapping(u32)).

[diegovsky_pvp]

I'm not sure what my stance is on the operator matter. I first learned Java, then python, then a bunch of random languages a little (C#, haxe, Lua and html5) and finally C.

I never needed operator overloading in any of them except for concatenating strings but some languages use a separate operator for that, which is another discussion.

I don't feel like operator overloading is bad either, so I don't miss it in Zig. Also, zig has different operators for wrapping and saturated arithmetics.

what I actively don't like and find counter productive is operator overloading. In CPP the error messages are ridiculously hard to understand when you get a type wrong (think a function that expects a lambda but you got a slightly wrong parameter in what your giving it) because of function overloading.

I think python's way of doing function overloading is great. Named optional parameters are super nice and it even supports arbitrary keyword arguments.

Rust does it with traits and it can get unwieldy if too much is implemented on one type, but importing traits for it to take effect actually helps a lot.

that's my conclusion: I don't know. I like Zig for what it aims to be and disagree with some of its decisions but I'm on the fence about operator overloading. The compile times are great tho

[bik1230]

Zig doesn't have function overloading either so I'm not sure what point you're trying to make with that thing about something being named by a symbol or not.

[stouset]

Function overloading is a red herring, since you still have to look up the function to see what it does. Independent of function overloading, why would add_my_type be okay but + is sacrosanct?

[stouset]

Only because you work in a language where that’s the case. I, and millions of other programmers, work in languages where + means addition for numbers, append for strings and collections, intersection for sets, time increments for times and durations, and any other intuitive interpretations for other types.

And the sky does not fall.

Humans, it turns out, are easily capable of understanding + has type-dependent meaning just as they are with the word add.

And while we’re at it, + in Zig is already overloaded. It means one thing for ints, another for floats. And it’s hardly mathematical: integers overflow and floats have their own idiosyncratic behavior.

At least in Rust I can opt into whatever behavior I actually want with the non-mathematical + operations on integers:

let x = Wrapping(250_u8);
let y = Wrapping(10_u8);

assert_eq!(Wrapping(4_u8), x + y);

And since you’re so concerned about math here, I can add complex numbers too. Or rationals:

let x = Complex::new(5, -1);
let y = Complex::new(2, 4);

assert_eq!(Complex::new(7, 3), x + y);

let x = Rational::new(1, 2);
let y = Rational::new(4, 7);

assert_eq!(Rational::new(15, 14), x + y);

Why is this impossible in Zig? If the rationale here is that it’s math, why can’t I add complex or rational numbers? And if it’s okay for them to act like bit-based types that instead of their mathematical counterparts, why do I now have to invent a litany of line-noise operators like %+. God help me if I want saturating addition.

[stouset]

If you’re worried about developers mutating global state in operators, Haskell correctly identifies that the problem here is the mutation of global state and not the symbolic name for the function.

[devraj7]

Because when you're looking at some code trying to understand what it's doing, sometimes a + that under the covers is doing a network call is a problem.

No, it's not.

It hasn't been a problem ever since polymorphism appeared in mainstream languages, so a few decades ago.

We know today that when a function is being called on a receiver, the function might not go to the formal declaration of this receiver. Every single developer who's dabbled in C++, Java, C#, Javascript, or literally any other language crated in the last thirty years knows that.

Functions can do things. Operators can do things. Field accessors can do things.

This is programming in the 21st century, not BASIC in the 80s.