return _, _, err
return StructA{}, StructB{}, nil, 0, "", err
return _, _, _, _, _, err
On Tue, Sep 24, 2013 at 5:29 PM, Nigel Tao <nige...@golang.org> wrote:Heh, I literally just came across another example of where I'd like
> Having said that, I wanted "_ means zero of any type" because
> zero-valued structs are relatively verbose compared to 0, "" or nil.
> I'm talking about the "image.Config{}"s in the
> return image.Config{}, etc
> lines at the bottom of
> https://code.google.com/p/go/source/browse/src/pkg/image/jpeg/reader.go
this. I have some code that says:
type foo struct { etc }
var f foo
// more code
if f != (foo{}) {
etc
}
The parens are unfortunately necessary because otherwise the first {
is parsed as starting the if's body instead of a struct literal. It
would be nicer if I could say
if f != _ {
etc
}
But again, it's not a big deal. I'd like to have it but I'm not going
to rage-quit using Go because of not having it, and unlike a language
change like s[i:j:k], it doesn't let me do anything I can't already
do.
Yep, this is why in my head I think of this as my "zero" proposal -- I think "f != zero" reads quite nicely.
Andrew
--
However, using the new syntax, the programmer could writereturn _, _, _, _, _, err
This makes the code more clear, in the sense that it clearly conveys the programmer's intention that he really only wants to return an error, and that all other return values are not meant to be used.
To sum up, the benefits would be:
1. Less key strokes.
I agree that if we were forced to address this "need", then I'd rather see a predeclared identifier besides the blank identifier being used for this purpose (since `x == _` looks a lot more "magical" to newcomers than the alternatives), and further, would rather avoid introducing a new predeclared identifier.I acknowledge that "nil vs nil" is a point of confusion for many people, though changing it as proposed would just shift the issue, wholly intact, to a "zero vs zero" problem, whereby people would wonder why the latter expression in `ptr := new(int); ptr == zero` would yield false; after all,
It's no assigning to nil. It's declaring and initiating a new variable that's called nil. Uses of nil outside that scope are unaffected.
Chris
My intent was to demonstrate that if a new predeclared identifier was introduced, then it would not break code as Derek implied. I don't condone writing real code that uses the trick I showed; I just wanted to point out a consequence of the scoping rules.
That aside, I'm rather ambivalent toward this proposal. I'm not sure whether it actually makes the code any clearer.
-Ross