Syntax extension proposal: return _, err

[derekc...@gmail.com]

I brought this up in #go-nuts today and there seemed to be a reasonable amount of interest, so I decided to throw it here to see what you guys think.

Since this is a syntax extension, I want to put it up front that the change would NOT break compatibility with existing code.  It's merely an addition.

TL;DR:  Use _ in return to represent zero values.

Example:

return _, _, err

Rationale: functions which return multiple values usually return an error by doing something like:

return StructA{}, StructB{}, nil, 0, "", err

Now this example is deliberately long, but it illustrates the point that the return clause is filled with useless cluster.  All return values other than err are not meant to be used, and yet the programmer is forced to manually put in those zero values for their appropriate types.

However, using the new syntax, the programmer could write

return _, _, _, _, _, 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.

The compiler, on the other hand, would convert those _ to the zero values of their corresponding type.  For example if you do "return _, _, err" in a function that returns (int, []string, error), the compiler would convert the statement to "return 0, nil, err".

To sum up, the benefits would be:

1. Less key strokes.
2. Intention made more clear.

[Dave Cheney]

not lgtm.

You've invented a new syntax for something which was clearly defined
beforehand -- you've _added_ ambiguity.

Instead of trying to make

return StructA{}, StructB{}, nil, 0, "", err

faster to type, I think you should question why you need to

a. return so many values
b. why do they need to be a mix of value and pointer types

If you decide that you do need to return all those valyues, in the
existing Go toolkit there exist several solutions to this problem,
including

* named return arguments
* defining a package private zero value for those params
* labeled goto, ie, goto error

Cheers

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Rob Pike]

Also, _ as it exists is write-only. You're introducing a new meaning
for it, which is unwise.

-rob

[Keith Rarick]

I made a similar (and similarly misguided) suggestion
about three years ago:
https://groups.google.com/d/msg/golang-nuts/VXWNJQFCgts/V2ED_W_tCdEJ

(Side note: wow, remember when map deletion had its own syntax?)

[Nigel Tao]

On Tue, Sep 24, 2013 at 1:44 PM, Keith Rarick <k...@xph.us> wrote:
> I made a similar (and similarly misguided) suggestion
> about three years ago:

Heh, I made a similar suggestion 18 months ago.
https://groups.google.com/forum/#!msg/golang-dev/iAysKGpniLw/qSbtBUx4-sMJ

[Nigel Tao]

On Tue, Sep 24, 2013 at 1:25 PM, Dave Cheney <da...@cheney.net> wrote:
> If you decide that you do need to return all those valyues, in the
> existing Go toolkit there exist several solutions to this problem,
> including
>
> * named return arguments
> * defining a package private zero value for those params
> * labeled goto, ie, goto error

First, being on the Go team, I appreciate more than most that language
changes are very unlikely.

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

As another example, some people don't like using chan struct{} or
map[T]struct{} even though the actual values sent or mapped don't
matter, because sending or adding the zero value, struct{}{}, looks
ungainly.

As another example, look at all the
return fileMetadata{}, err
lines in the DB.writeLevel0Table method in
https://code.google.com/p/leveldb-go/source/browse/leveldb/leveldb.go

It's true that, as you say, there are different ways of writing this.
The leveldb example actually has named return values, but I avoid
saying
return meta, err
or just
return
because meta isn't necessarily zero. It can be partially initialized,
and I'd rather follow the idiom that if the returned error is non-zero
(i.e. non-nil) then all other return values are zero. I also generally
avoid "naked returns" because of the possibility of local variables
(especially those named "err") shadowing return values.

A package-private zero is do-able. Heck, the image package defines
public zeroes image.ZP and image.ZR because they're shorter to write
than image.Point{} and image.Rectangle{} (and possibly date from
before we had struct literals??). But image.ZP is really a hack; it
shouldn't be a *variable*.

Relatedly, the image/draw package has two key functions Draw and DrawMask, and
Draw(dst, r, src, sp, op)
is really just short-hand for
DrawMask(dst, r, src, sp, image.Point{}, nil, op)
but if I could use _ for wildcard-zero, then I'd only really need just
the one function, and could write:
DrawMask(dst, r, src, sp, _, _, op)
everywhere I currently write Draw, which doesn't seem so bad. As a
bonus, sp is very often the zero point, so that could also be _
instead of image.Point{} or image.ZP.

Labelled gotos are also do-able, but I'd still rather say "return _, err".

Anyway, as I said, language changes are very unlikely, so I live with
it and move on. It doesn't stop me from writing useful code and having
fun. But as I said 18 months ago, speaking purely personally, I'd like
_ to be more like /dev/zero than /dev/null.

Rob is right, though, that it does introduce a new meaning for _. You
can return nil and assign nil and pass nil to a function, and the
compiler can infer the type of that nil, but you can't assign *to* nil
or `import nil "foo"` the way you can say "_ = x" or `import _ "foo"`,
so adding this new feature isn't a no-brainer.

[roger peppe]

Another possibility would be to allow nil itself to represent a zero
value of any type.

[Jan Mercl]

On Tue, Sep 24, 2013 at 12:07 PM, roger peppe <rogp...@gmail.com> wrote:
> Another possibility would be to allow nil itself to represent a zero
> value of any type.

If one names the function return values then there is always a
complete set of zero values (for every returned type) ready to
use/return available.

IMO there's no good reason to consider the OP proposal. Good reasons
why to reject it were already presented in this thread by others.

-j

[Dave Cheney]

Whoa. In that case I'd choose the lesser evil and go with the _ proposal.

[roger peppe]

On 24 September 2013 11:14, Jan Mercl <0xj...@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 12:07 PM, roger peppe <rogp...@gmail.com> wrote:
>> Another possibility would be to allow nil itself to represent a zero
>> value of any type.
>
> If one names the function return values then there is always a
> complete set of zero values (for every returned type) ready to
> use/return available.

I'm not keen on doing that in general, because you then have
to check back into the body of the function to see if the
named return value has been modified.
And in fact, it may have been, in which case you haven't got
a zero value any more.

As one data point in this dicussion, unrelated to the above
remark, here's a random example from
our code base which is working around the issue
by declaring a local variable:

func (u *UniterAPI) getOneRelationById(relId int)
(params.RelationResult, error) {
nothing := params.RelationResult{}
rel, err := u.st.Relation(relId)
if errors.IsNotFoundError(err) {
return nothing, common.ErrPerm
} else if err != nil {
return nothing, err
}
// Use the currently authenticated unit to get the endpoint.
unit, ok := u.auth.GetAuthEntity().(*state.Unit)
if !ok {
panic("authenticated entity is not a unit")
}
result, err := u.prepareRelationResult(rel, unit)
if err != nil {
// An error from prepareRelationResult means the authenticated
// unit's service is not part of the requested
// relation. That's why it's appropriate to return ErrPerm
// here.
return nothing, common.ErrPerm
}
return result, nil
}

[Nigel Tao]

On Tue, Sep 24, 2013 at 8:14 PM, Jan Mercl <0xj...@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 12:07 PM, roger peppe <rogp...@gmail.com> wrote:
>> Another possibility would be to allow nil itself to represent a zero
>> value of any type.
>
> If one names the function return values then there is always a
> complete set of zero values (for every returned type) ready to
> use/return available.

The very first line of the DB.writeLevel0Table method that I mentioned
earlier is:

func (d *DB) writeLevel0Table(fs db.FileSystem, mem *memdb.MemDB)
(meta fileMetadata, err error) {
meta.fileNum = d.versions.nextFileNum()
etc
}

So I don't have a complete set of zero values ready to use for the
rest of the body.

[Jan Mercl]

Yes, you don't have a zero value of a variable after setting it to a
non zero value, agreed. But I don't get the point. Also, there's an
option to do:

meta.fileNum, zmeta := d.versions.nextFileNum(), meta

What I was trying to say is that the compiler worked hard to create
those zero values [0], so why not to use them if required? By 'always'
I meant on entry to the function, which I didn't said explicitly. My
fault.

[0]: Don't know how at tip, but there used to be a time when the zero
values of return values were actually zeroed in code, on entry to a
function, even when later never used at all if the code contained no
naked 'return' statement.

-j

[Robert Johnstone]

I agree.  I'm not convinced that named return variables were a net positive.

[Kyle Lemons]

I have often wondered if we can solve this quirk along with fixing the nil dilemma (nil being both the zero pointer and zero interface).  I'm probably not going to write this up formally until the day that the Go team decides that it might be time for go2, but I think that introducing a "zero" in addition to "nil" would be one solution: zero is convertible/assignable to every concrete type, and nil is only an empty interface.  One up-side would be that "iface == zero" (the way someone might erroneously try to compare to the zero pointer) is now an error, and "iface == nil" is clearly only checking that it's an empty interface.

[appleb...@gmail.com]

I like named return values purely for the way they aid function documentation, especially when there's more than one return value. But even when I use them, I almost never use the unadorned return statement. I find unadorned returns generally make code harder to read, because you have to scroll up and examine the function declaration in order to understand what the function is actually returning.

[Luke Scott]

What about:

return ,, err

Instead of changing the meaning of "_", you could leave it completely blank to mean "zero value".

[Nigel Tao]

On Tue, Sep 24, 2013 at 5:29 PM, Nigel Tao <nige...@golang.org> wrote:
> 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

Heh, I literally just came across another example of where I'd like
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.

[Kyle Lemons]

On Tue, Sep 24, 2013 at 5:42 PM, Nigel Tao <nige...@golang.org> wrote:

On Tue, Sep 24, 2013 at 5:29 PM, Nigel Tao <nige...@golang.org> wrote:
> 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

Heh, I literally just came across another example of where I'd like
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
}

Yep, this is why in my head I think of this as my "zero" proposal -- I think "f != zero" reads quite nicely.

 

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.

[Andrew Gerrand]

On 25 September 2013 12:13, Kyle Lemons <kev...@google.com> wrote:

Yep, this is why in my head I think of this as my "zero" proposal -- I think "f != zero" reads quite nicely.

Did you know that nil and zero are synonyms?

Andrew

[Kyle Lemons]

I do.  We use the term "zero value" in numerous places, though, so I think the distinction between "zero" being convertible to all concrete types and nil being restricted to interfaces would be natural enough.

 

Andrew

[roger peppe]

You couldn't restrict nil to interfaces - what about maps, channels,
pointers and slices?
Or would you deprecate nil for those kinds and make this a Go 2 feature?

I quite like "zero" BTW. I see two possibilities (if we don't want to
break existing code):
1) make it compatible only with types that can't currently be nil.
2) make it represent a zero value of any type (a strict superset of nil)

I like the former because it means that an occurrence of "zero" in a program
carries slightly more information; I like the latter because it has more
conceptual integrity (it matches well to reflect.Zero, for example).

[Robert Johnstone]

Why don't you just use 0 (an untyped constant) instead of introducing a new keyword?

Also, the proposal may be more acceptable if it was narrower.  Perhaps allowing 'zero' or '0' to implicitly convert to a struct instead of all concrete types.

On the other hand, I've not run into this problem myself, so I don't know if it would be a net win for readability or not.

[Dave Cheney]

I think that would be a net loss for readability, consider this example

func hello(i int) (string, time.Time, net.Conn) {
if i == 1 {
return 0, 0, 0
}
// else do it right
}

Confusing to say the least.

[Aram Hăvărneanu]

Because sometimes you just want to return a 0 in a non-error case.

--
Aram Hăvărneanu

[Ian Lance Taylor]

On Wed, Sep 25, 2013 at 6:00 AM, Robert Johnstone
<r.w.jo...@gmail.com> wrote:
> Why don't you just use 0 (an untyped constant) instead of introducing a new
> keyword?

Not sure where I stand on this idea, but, to be clear, zero would not
be a keyword, any more than nil is a keyword. Zero would be a
predeclared identifier.

Ian

[Matt Harden]

I would not use 0 for this. That would mean 0 would be treated specially compared to all other untyped numeric constants. I wouldn't want to use nil either because it should imply an empty reference to something vs. a zero value. People are used to NULL in C++, and I think nil fits that role. I like "_" for this because it reminds me of /dev/null in Unix - a trashcan on write, empty on read, and it's easy to type and IMHO easy to read.

[derekc...@gmail.com]

Seems like many people are in favour of having a constant value to represent zero value.  The three existing proposals seem to be

1. _ (the original proposal)
2. 0
3. zero (or some other new key word)

I would vote against 0 for reasons already suggested: that 0 should just be a numeric constant.

I'm personally fine with either _ or zero.  But using _ means we don't have to introduce one more keyword; plus using "zero" might break some existing code that happen to use "zero" as a variable name.

[Ross Light]

Not if it's made a predeclared identifier, like some "keywords" in Go.

A rather extreme example: http://play.golang.org/p/-wVTiXk3q9

Ross Light | Software Engineer | li...@google.com                       

--

[Benjamin Measures]

On Monday, 23 September 2013 23:26:50 UTC+1, Derek Chiang wrote:

However, using the new syntax, the programmer could write

return _, _, _, _, _, 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.

Why can't we just using the idiomatic nil, rather than have *another* language extension [proposal]? For example, net.ParseCIDR:

return nil, nil, err

To sum up, the benefits would be:
1. Less key strokes.

I like the occasional perl golf as much as the next guy but the phrase "less is exponentially more" wasn't referring to key strokes.

[Kevin Gillette]

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, the data pointed to by ptr equals zero, right?

Perhaps the simplest change would be to allow nil to be assigned to anything that doesn't already have a suitable predeclared identifier or constant. This would mean that you could not do `var x int = nil`, since 0 already exists as a constant representing that type's zero value. Nor could you do `var x bool = nil`, but you could do `var x struct{} = nil`.  Still, I'm not convinced that there's an overwhelming need.

[Steven Blenkinsop]

On Fri, Sep 27, 2013 at 7:35 PM, Kevin Gillette <extempor...@gmail.com> wrote:

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,

If zero were only assignable/comparable to struct and array types, then this wouldn't be an issue. Of course, this wouldn't resolve the `interface{}((*T)(nil)) != nil` thing. If you made it so only interfaces could be `nil` to fix this, where everything else that can currently be `nil` can be `zero`, then yes, you'd still have `ptr != zero && *ptr == zero`, but this is fundamental to pointers and less of a tripping point (you don't have `x = nil; y = x; y != nil`), and is equivalent to `prt != nil && *ptr == nil', which can currently arise anyway (though admittedly less commonly than the `zero` case).

[Dan Kortschak]

A tweak to this (at the cost of identifier proliferation) would be nil for pointer, zero for non-pointer concrete values, and 'empty' (or some other, since the empty interface is a type) for interfaces.

[Kevin Gillette]

if you're going in that direction, we could just introduce a "really" qualifier and just use "empty" for everything: concrete types can be assigned `empty`, pointers can be assigned `really empty`, and interfaces can be assigned `really really empty` :-P 

[Dan Kortschak]

Then can we add "like" to the collection of ignored tokens? ;)

[Jsor]

I'm also naughty with my desires for _ to be overloaded to mean "I don't care what this value is right now", but for me it's in a different context. Sometimes I want to write a closure like this:

func AddThree(a, b, c int) int {

  return a + b + c

}

func AddThreeConstCFunc(c int) func(int,int) int {

  return func(a,b int) int {

    return AddThree(a,b,c)

  }

}

But that's not what my brain wants to do, every time I have to write something like that, I instinctively do this:

func AddThreeConstCFunc(c int) func(int,int) int {

  return AddThree(_,_,c)

}

(Obviously this isn't a real example, I don't usually make a function for adding three numbers). My instinct to do this is weird, since the syntax is kind of Prolog-y and I hate Prolog, but it's a really, really strong instinct, and feels natural to me. Ah well.

[Kevin Gillette]

That's a lot more confusing than, e.g. a short-hand lambda notation, which would allow both return expression manipulation and argument reordering too:

func AddThreeConstCMinus1Func(c int) func(int, int) int {

  return (a, b) { AddThree(b, a, c) - 1 }

}

(in this non-propsal, essentially it's a Go func signature without the func keyword or types (inferred), and with an implicit return keyword, all only allowed if the function body contains only an expression list).

Still, while Go does well enough in the functional programming world, it's not nearly a predominantly FP language, which is what it'd take to warrant special syntax for closures or lambdas (which in the above case, only brings a 51 character, much more readable function literal down to 32 characters).

[Miroslav Puda]

Use of '_' here seems ambiguous to me. I can also think about AddThree(0, 0, c) in case of '_' as zero value. In Haskell '_' is used as "I don't need this value" or "everything else". Here it is used as "pass some value here" which seems to be quite opposite of "I don't care about this". You are making '_' context sensitive which makes higher demands on reader of code.

Dne sobota, 28. září 2013 8:10:42 UTC+2 Jsor napsal(a):

[RickyS]

I did not know it was possible to assign to nil.  It seems like a disastrous decision.
I was, in fact, about to ask whether there was any difference between a keyword and a predeclared identifier.
Now that I know, I wish I didn't...

[chris dollin]

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

[Ross Light]

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