error for ignoring return value

[andrewrk]

if a function has a return value, you must handle it, at least by assigning it to _

[zatherz]

This is a terrible idea IMO. There are many cases where you want to have a function that returns extra information, like system.raise(system.SIGABRT);, but the name doesn't indicate that.

[thejoshwolfe]

In any case where you would run into this error, you can resolve it by assigning to _. Can you elaborate on why doing this is worse than leaving the possibility of a return value hidden to someone reading the code? Hassling the code writer to help the code reader is sorta in line with Zig's design goals.

[thejoshwolfe]

@zatherz See the changes to std/ and test/ in c6605cb for a real world example of this change forcing a zig author to assign to _. In this particular case, the hassle was usually not interesting, but it actually did catch one bug where the number of bytes from a read() was being ignored instead of checking it for an early EOF error situation.

This is a data point in favor of keeping the error for ignoring function return values.

[zatherz]

What about some sort of operator specifically for ignoring return values, so that you don't have to clutter code with _ =?

[andrewrk]

I don't follow that logic. _ = is 2 characters and it follows an existing pattern so that you don't have to learn something new. Why is introducing a new operator better?

[zatherz]

It's 4 characters (_<SPACE>=<SPACE>). When I see = I assume that something is being set for later use, not discarded.

[thejoshwolfe]

In C you have (void)foo() to ignore the return value of foo(). I think that's much worse than Zig's _ = foo(), not only for being more characters, but also for making very little sense.

If we introduced a 1-character operator for ignoring the return value, we'd be adding another 1-character symbolic operator for basically no purpose. Like the operator would actually do nothing. That doesn't seem worthwhile when the current solution to the problem works fine.

_ = is a little bulky, but 2-4 characters doesn't really seem that bad. If Zig follows the design philosophy of minimizing keypresses to make Zig code as terse as possible, we end up with an operator-heavy language that's hard to learn. See #340 for a motion away from operators towards a few more characters for the sake of readability.

Obviously languages can be designed however the designer(s) want them to be designed, so this is a bit of an arbitrary decision. But Zig's design does have an emphasis on readability and being a small langauge, so I think the current solution is consistent with Zig's philosophy.

Just for reference, the _ special identifier is used in Zig anywhere where you need to use a variable, but you don't actually care about reading from it. So you can assign to _ to discard a value, and you can declare a parameter or multiple parameters as _ if you're not going to read from the parameters, and you can declare your captured value (e.g. in a for loop) as |_| to mean that you don't actually care what the variable is. This use of _ to mean discard is taken from Haskell, which I know isn't an especially readable language, but Zig uses it consistently, and so learning how to ignore a return value from a function is included in learning about the _ special identifier.

[xyproto]

Go also uses _ to ignore values, but also allows multiple ignores, like:

_ = 42
_, _, _ = 1, 2, 3