It's not so much that it allows it to be ignored, it's that if you want it to be ignored, you have to use that keyword. It means that there's syntactic noise in cases where you don't care about the return value of a function that has one, and thus discourages you from writing functions like that.
I read your comment more as an endorsement of implicit returns. Make no mistake, I love those. I've been using them most of my life, first in OCaml and then in Scala.
I just think that using the semicolon to make the function return unit instead is problematic. It would be better to have the type system guide that decision, like in Scala. It would be even better to have an explicit `ignore` function or something (like in OCaml) to signal to the compiler that you really want to ignore the value and you only care about uthe side effect. I mean, why would you ever write just e.g. `a < b;`?
Being able to ignore return values is something that C had before they had function prototypes. The compiler didn't know if something returned a value, so it couldn't check. There's no good reason for that misfeature in a newer language.
Go apparently does it that way to make "defer" work.[1]
>> Ignoring the return value from a non-void method.
Beginners might also write a method/function with a return parameter they don't care about (or that they sometimes don't care about) but that has some desirable side-effect.
In OCaml, you're required to do something with the return from any non-void function. You can just say "ignore (f x)" to discard the result, so it's not hugely inconvenient, but causes suspect code to accumulate warning signs.
I think what GP is getting at that if you call a function with one return value, you can ignore it by not assigning anything to the result of the function.
Sorry, yes, you are of course right. That's the linter which complains, not the compiler.
I have to say that I don't understand the rationale of a compiler that errors on unused variables but lets the user silently ignore function return values. As a solution to explicitly ignore return values already exists in the language.
I don't see how a keyword that allows return values to be ignored creates an incentive to create void functions.
I sort of find the idea refreshing myself. As a full time Clojure developer, I consider Nim to be the closest thing I can find to what I want for a great experience coding closer to the bare metal.
Without a named keyword, a void function can use the return keyword to terminate control flow conditionally. So it's only orthogonal in the case of a function with a typed return value.
Which is fine. I have no problem with it. I'm a Haskell/ Clojure/Erlang/TypeScript/CL developer, so I'm used to this. But golang users beat me over the head with the "simplicity" of Go and use examples of Haskell and Clojure having lexical scopes change common keywords as examples of the "excessive complexity of !Golang".
I'm not asking you to defend an argument you didn't make, but I think Go folks need to own that this is actually a code smell for something that could be done differently a scoped variable.
I think forgetting to assign a variable to the return value and ignoring the return value are two different things.
Zig regards forgetting to assign a variable to a return value as a compile time error because there's an entire class of bugs that stem from it, e.g. resource leaks.
The idea behind this feature is to ensure that you don't lose important data, not to discourage you from writing functions which return values. For cases where a functions return value is truly optional, you can use the {.discardable.} pragma.
That's perfectly acceptable and expected. F# supports OOP and imperative just as much as it does functional programming. In the case of such functions and expressions, the value returned is of type `unit` with a single value of `()`. In F#, expressions that return `unit` have the value explicitly ignored if they are not the last expression in a code block. Other expressions returning non-`unit` values that aren't at the end of an expression will generate a warning. In such cases, for example where a function performs a required side effect and returns a value other than `()` but you don't need that value, you can use `|> ignore` to get rid of the warning since it says you are explicitly wanting to ignore the returned value.
It's not clear to me what this new keyword should do when a function has more than one value to return. Does it always use a zero value? What if a user wants to return something else?
You can ignore error values returned just like you can ignore the numeric value returned from atoi. That's the point. They're just values. You are the programmer, it's your job to decide what to do with any particular value returned by a function.
reply