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.
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 should have used a better example, but there are a good number of cases where the Java compiler complains about missing return statements that just don't need to be there. It's a wart in the language.
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]
I respectfully disagree with this. Ignoring return values is _not_ good practice. It is a slippery slope to bad software. By catching these memory errors, a program has the chance to properly teardown and report a message to the user instead of crashing.
If you forgot to return a value, a function shouldn't have compiled. In Nim you can easily forget to return something or have a hole in your branching and get a defaulted value, instead of a compiler error.
In some cases an implicitly declared variable feels neat and convenient, but I'm not sure it's worth it.
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.
I like the "value return" approach here, and I've been considering using it for a project I'm working on. You have to provide a place for the error to go when you call the function. You can decide to ignore it, but you can't forget that it exists. I'd be interested in hearing a contrary position, however.
as long as you aren't calling what you consider to be a 'return void' function (like writing data to a socket). then it is easy to forget to check the return value.
i wonder how hard it would be for their compiler to catch the opposite case, then - a program using the return value of a function without a return statement. i think that was my most common bug when i was doing javascript programming, because all the other languages i was using at the time had implicit returns.
>> 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.
Oh Man, that can also cause a lot of issues. If you call a function that has a return value but you don't actually need it, like invoke-webrequest, but you use an explicit return statement right thereafter things go haywire. I have yet to produce a proof of concept to illustrate this issue, but I came across this and it actually overwrites my return statement with the orphaned return value from the invoke method. Took me ages to figure out what was wrong, because debugging the application I could see inside the function that the variable I was returning had the expected value, but what was being bound to the outside was something completely different
The complaint about 'implicit information loss' is a bit weird, the code calls a function/method that may do other things, the compiler doesn't know whether you intend to ignore what's returned or not. To return 'true' when you meant to return the result of the function call on the previous line is just a bug. There are going to be bugs.
Relying on code review to catch bugs is just leaving it up to a different programmer. Code review is wonderful, but expecting it to catch every occurrence of even just the categories of bugs easily caught by code review is wildly overoptimistic.
Ignoring the second return value is also the easy case to catch. Ignoring an error-only return from a function doesn't produce a warning, and won't stand out in code review unless you adopt a standard of never writing void functions.
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.
reply