It is apparently quite easy to think that b refers to something which it did earlier, when it actually refers to something newer than that.
This makes more sense as a problem if you rename it err instead.
1 Like
Only : part is for declaration, so suffering a bit of lack of aesthetics, something like
var1, ok := foo1()
var2:, ok = foo2()
could work. But overall this is not a good idea.
This is hard to spot and relying on “multiple return values can only be declared altogether” removes some mental overhead when reading the code.
This syntax is ambiguous still. How do you declare the ok but reuse the variable before? Your syntax cannot allow for it.
var, ok := foo()
var:, ok = foo()
var, ok: = foo() // same as the first one
var, ok: := foo() // ambiguous with `::` followed by `=`
There is a reason I said this twice:
I AM NOT LOOKING FOR SYNTAX SUGGESTIONS. PLEASE DO NOT GIVE ME THEM!
I thinking more and more that this idea has more cons than it has pros.
2 Likes
f, ok := foo()
b, ok := bar()
Why the second ‘ok’ is not allowed? The language allow shadow .
But what if reusing only the most right-hand variable was allowed? (Kinda the same exception to the rule as or_* stuff)
1 Like
The language allows showing in nested scopes NOT within the same scope.
Still no. I want things to work as expected.
I can see how this can be useful in some cases (like you pointed out), but I think it’s too much of a niche to be bothered.
I’d find this useful to catch an error and handle it but still benefit from defer if err != nil semantics. It could be achieved by adding a keyword that sets the last return value like an or_return but doesn’t return so you can then do if err == .File_Not_Found right after