>> 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.
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.
> No return value needed (compiles down to an Action<T> I think)
Which is an other crufty thing in C#: because Void/() is not a type (inherited from Java), it needs to have both `Func<Tn..., T>` and `Action<Tn...>` in order to handle functions-with-a-return-value and functions-without-a-return-value.
To me, your example says: "I forgot about the return value." The way I learned C, if you really, really want to say "I don't care what the return value is" you'd explicitly cast it, nicely documenting your active non-caring about the return value for future code readers:
(void) printf("Hello, World!\n");
Although, in general, ignoring the return value from things like puts() and printf() is a bad idea, for reasons the article makes clear.
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.
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 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.
> It's a bad idea for the same reason that having a function that returns back multiple values is a bad idea.
Every single language that lacks multiple return values has some kind of hack to compensate, like varying parameters, that breaks encapsulation and makes code inconsistent.
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.
In my opinion, the site you linked to has a major problem - many of the example functions have a "void" return type. This indicates that they must have side-effects (or why else call them?) and we would normally not want to write functions that have side effects.
A rule of thumb: if your function doesn't have a return type, consider that your design maybe wrong in some way.
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.
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.
reply