New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: reduce noise in return statements that contain mostly zero values #21182

Closed
jimmyfrasche opened this Issue Jul 26, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@jimmyfrasche
Member

jimmyfrasche commented Jul 26, 2017

Closed in favor of a universal zero value, see #19642 (comment)

Proposal

In return statements, allow ... to signify, roughly, "and everything else is the zero value". It can replace one or more zero values.

This is best described by example:

Given the function signature func() (int, string, *T, Struct, error):

return 0, "", nil, Struct{}, nil may be written return ...

return 0, "", nil, Struct{}, err may be written return ..., err

return 0, "", nil, Struct{X: Y}, nil may be written return ..., Struct{X: Y}, nil

return 1, "", nil, Struct{}, nil may be written return 1, ...

return 1, "a", nil, Struct{}, nil may be written return 1, "a", ...

return 1, "", nil, Struct{}, err may be written return 1, ..., err

return 1, "a", nil, Struct{X: Y}, err may be written return 1, "a", ..., Struct{X: Y}, err

The following is invalid:

return ..., Struct{X: Y}, ... — there can be at most one ... in a return statement

Rationale

It is common for a function with multiple return values to return only one non-zero result when returning early due to errors.

This creates several annoyances of varying degrees.

When writing the code one or more zero values must be manually specified. This is at best a minor annoyance and not worth a language change.

Editing the code after changing the type of, removing one of, or adding another return value is quite annoying but the compiler is fast enough and helpful enough to largely mitigate this.

For both of the above external tooling can help: https://github.com/sqs/goreturns

However, the unsolved problem and motivation for the proposal is that it is quite annoying to read code like this. When reading return 0, "", nil, Struct{}, err unnecessary time is spent pattern matching the majority of the return values with the various zero value forms. The only signal, err, is pushed off to the side. The same intent is coded more explicitly and more directly with return ..., err. Additionally, the previous two minor annoyances go away with this more explicit form.

History

This is a generalized version of a suggestion made by @nigeltao in #19642 (comment) where #19642 was a proposal to allow a single token, _, to be sugar for the zero value of any type.

I revived the notion in #21161 (comment) where #21161 is the currently latest proposal to simplify the if err != nil { return err } boilerplate.

Discussion

This can be handled entirely with the naked return, but that has greater readability issues, can lead too easily to returning the wrong or partially constructed values, and is generally (and correctly) frowned upon in all but the simplest of cases.

Having a universal zero value, like _ reduces the need to recognize individual entries as a zero value greatly improving the readability, but is still somewhat noisy as it must encode n zero values in the common case of return _, _, _, _, err. It is a more general proposal but, outside of returns, the use cases for a universal zero value largely only help with the case of a non-pointer struct literal. I believe the correct way to deal that is to increase the contexts in which the type of a struct literal may be elided as described in #12854

In #19642 (comment) @rogpeppe suggested the following workaround:

func f() (int, string, *T, Struct, error) {
  fail := func(err error) (int, string, *T, Struct, error) {
    return 0, "", nil, Struct{}, err
  }
  // ...
  if err != nil {
    return fail(err)
  }
  // ...
}

This has the benefit of introducing nothing new to the language. It reduces the annoyances caused by writing and editing the return values by creating a single place to write/edit the return values. It helps a lot with the reading but still has some boilerplate to read and take in. However, this pattern could be sufficient.

This proposal would complicate the grammar for the return statement and hence the go/ast package so it is not backwards compatible in the strict Go 1 sense, but as the construction is currently illegal and undefined it is compatible in the the Go 2 sense.

Possible restrictions

Only allow a single value other than ....

Only allow it on the left (return ..., err).

Do not allow it in the middle (return 1, ..., err).

While these restrictions are likely how it would be used in practice anyway, I don't see a need for the limitations. If it proves troublesome in practice it could be flagged by a linter.

Possible generalizations

Allow it to replace zero or more values making the below legal:

func f() error {
  // ...
  if err != nil {
    return ..., err
  }
  // ...
}

This would allow easier writing and editing but hurt the readability by implying that there were other possible returns. It would also make this non-sequitur legal: func noop() { return ... }. It does not seem worth it.

Allow ... in assignments. This would allow resetting of many variables to zero at once like a, b, c = ... (but not var a, b, c = ... or a, b, c := ... as their is no type to deduce) . In this case I believe the explicitness of the zero values is more a boon than an impediment. This is also far less common in actual code than a return returning multiple zero values.

@gopherbot gopherbot added this to the Proposal milestone Jul 26, 2017

@gopherbot gopherbot added the Proposal label Jul 26, 2017

@OneOfOne

This comment has been minimized.

Show comment
Hide comment
@OneOfOne

OneOfOne Jul 27, 2017

Contributor

Why not named returns? func f() (i int, ss string, t *T, s Struct, err error) {}

Contributor

OneOfOne commented Jul 27, 2017

Why not named returns? func f() (i int, ss string, t *T, s Struct, err error) {}

@rogpeppe

This comment has been minimized.

Show comment
Hide comment
@rogpeppe

rogpeppe Jul 27, 2017

Contributor

I like this idea, but I can't think of any place where I'd use it for anything other than filling in all but the last value. Given that, I think one could reasonably make it a little less general and allow only this form (allowing any expression instead of err, naturally)

return ...err

Note the lack of comma. I'm not sure whether it's better with a space before "err" or not.

Contributor

rogpeppe commented Jul 27, 2017

I like this idea, but I can't think of any place where I'd use it for anything other than filling in all but the last value. Given that, I think one could reasonably make it a little less general and allow only this form (allowing any expression instead of err, naturally)

return ...err

Note the lack of comma. I'm not sure whether it's better with a space before "err" or not.

@jimmyfrasche

This comment has been minimized.

Show comment
Hide comment
@jimmyfrasche

jimmyfrasche Jul 27, 2017

Member

@OneOfOne Naked returns are fine for very short functions but are harder to scale: it gets too easy to accidentally return partially constructed values or the wrong err because of shadowing. Other than that, or maybe because of that, I like the explicit syntax better. A naked return says "go up to the function signature to see what can be returned, then trace through the code to see what actually gets returned here" whereas return ..., err says "I'm returning a bunch of zero values and the value bound to the err in scope"

@rogpeppe that was the original syntax proposed that I based this proposal off of. I don't like it because it appears to be a spread operator common in dynamic languages so it's a bit confusing. Having the comma makes it superficially more similar to "⋯" in mathematical writing and with like purpose. I agree that this would almost always be used as return ..., last where last is a bool or error and sometimes as a return ..., but I don't see any particular reason to artificially limit it to that. If it's not very useful it will not get used often. Is there any particular concern that a line like return 7, ... would be more confusing or error prone than a return ..., true?

Member

jimmyfrasche commented Jul 27, 2017

@OneOfOne Naked returns are fine for very short functions but are harder to scale: it gets too easy to accidentally return partially constructed values or the wrong err because of shadowing. Other than that, or maybe because of that, I like the explicit syntax better. A naked return says "go up to the function signature to see what can be returned, then trace through the code to see what actually gets returned here" whereas return ..., err says "I'm returning a bunch of zero values and the value bound to the err in scope"

@rogpeppe that was the original syntax proposed that I based this proposal off of. I don't like it because it appears to be a spread operator common in dynamic languages so it's a bit confusing. Having the comma makes it superficially more similar to "⋯" in mathematical writing and with like purpose. I agree that this would almost always be used as return ..., last where last is a bool or error and sometimes as a return ..., but I don't see any particular reason to artificially limit it to that. If it's not very useful it will not get used often. Is there any particular concern that a line like return 7, ... would be more confusing or error prone than a return ..., true?

@rogpeppe

This comment has been minimized.

Show comment
Hide comment
@rogpeppe

rogpeppe Jul 27, 2017

Contributor

@jimmyfrasche I just don't see that it would ever be used, and given that, the comma seems like unnecessary overhead for what would be a very commonly used idiom.

How many places in existing code can you find where eliding all but the first argument (or all but several arguments) would be useful?

Contributor

rogpeppe commented Jul 27, 2017

@jimmyfrasche I just don't see that it would ever be used, and given that, the comma seems like unnecessary overhead for what would be a very commonly used idiom.

How many places in existing code can you find where eliding all but the first argument (or all but several arguments) would be useful?

@ianlancetaylor

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Jul 27, 2017

Contributor

If we permit both ..., v and v, ... how do we justify the exclusion of ..., v, ...? Except for that fact that it is impossible to implement?

Contributor

ianlancetaylor commented Jul 27, 2017

If we permit both ..., v and v, ... how do we justify the exclusion of ..., v, ...? Except for that fact that it is impossible to implement?

@jimmyfrasche

This comment has been minimized.

Show comment
Hide comment
@jimmyfrasche

jimmyfrasche Jul 27, 2017

Member

@rogpeppe return ...aSlice looks too much like https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator That's not a strong argument against it, but I'd still rather not see it. While I would be surprised if this proposal is accepted in any form, I certainly wouldn't be mad if that variant was the one accepted, as it is the most common case. I really don't see any justification for the limitation, personally. It would be interesting to run an analysis on go-corpus to see if there are any. I don't have the time to do that for a bit, so anyone can feel free to beat me to it.

@ianlancetaylor that's a fine point. Impossible to implement is justification enough for me. Though it would be possible to implement in some cases, where v is of a type returned only once, but then subtle and distance changes could make it suddenly ambiguous. I would note that the other two existing uses of ... are also "at most once". You can't do func(a ...string, b ...int) or append(bs, s1..., s2...) even though the first is only sometimes unambiguous and the latter would be merely inefficient (or rather non-obviously inefficient).

Another option, that I'm fairly sure is a bad idea, would be to allow "keyed returns" to work in conjunction with named returns, by analogy with keyed struct literals:

func() (a int, b string, err error) {
  // ...
  if err != nil {
    return err: err
  }
  // ...
  return b: name, a: -x // I purposely flipped the order here
}

though that would interact poorly with the semantics of the naked return. If a is non-zero what happens when I write return err: err? The answer should clearly be that only err is returned, but it's still a potential source of confusion.

Member

jimmyfrasche commented Jul 27, 2017

@rogpeppe return ...aSlice looks too much like https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator That's not a strong argument against it, but I'd still rather not see it. While I would be surprised if this proposal is accepted in any form, I certainly wouldn't be mad if that variant was the one accepted, as it is the most common case. I really don't see any justification for the limitation, personally. It would be interesting to run an analysis on go-corpus to see if there are any. I don't have the time to do that for a bit, so anyone can feel free to beat me to it.

@ianlancetaylor that's a fine point. Impossible to implement is justification enough for me. Though it would be possible to implement in some cases, where v is of a type returned only once, but then subtle and distance changes could make it suddenly ambiguous. I would note that the other two existing uses of ... are also "at most once". You can't do func(a ...string, b ...int) or append(bs, s1..., s2...) even though the first is only sometimes unambiguous and the latter would be merely inefficient (or rather non-obviously inefficient).

Another option, that I'm fairly sure is a bad idea, would be to allow "keyed returns" to work in conjunction with named returns, by analogy with keyed struct literals:

func() (a int, b string, err error) {
  // ...
  if err != nil {
    return err: err
  }
  // ...
  return b: name, a: -x // I purposely flipped the order here
}

though that would interact poorly with the semantics of the naked return. If a is non-zero what happens when I write return err: err? The answer should clearly be that only err is returned, but it's still a potential source of confusion.

@mewmew

This comment has been minimized.

Show comment
Hide comment
@mewmew

mewmew Aug 12, 2017

Contributor

Counter-proposal that has been suggested elsewhere in the past (#19642). Allow _ to be used as the zero value of any type in expressions. Currently _ in var _ T = foo may be thought of as foo > /dev/null (from Effective Go). Similarly, _ in var foo T = _ could be thought of as foo < /dev/null. Then _ could be used in return statements.

E.g. given the function signature func() (int, string, *T, Struct, error):

return 0, "", nil, Struct{}, nil may be written return _, _, _, _, _

return 0, "", nil, Struct{}, err may be written return return _, _, _, _, err

return 0, "", nil, Struct{X: Y}, nil may be written return _, _, _, Struct{X: Y}, _

return 1, "", nil, Struct{}, nil may be written return 1, _, _, _, _

return 1, "a", nil, Struct{}, nil may be written return 1, "a", _, _, _

return 1, "", nil, Struct{}, err may be written return 1, _, _, _, err

return 1, "a", nil, Struct{X: Y}, err may be written return 1, "a", _, Struct{X: Y}, err

Contributor

mewmew commented Aug 12, 2017

Counter-proposal that has been suggested elsewhere in the past (#19642). Allow _ to be used as the zero value of any type in expressions. Currently _ in var _ T = foo may be thought of as foo > /dev/null (from Effective Go). Similarly, _ in var foo T = _ could be thought of as foo < /dev/null. Then _ could be used in return statements.

E.g. given the function signature func() (int, string, *T, Struct, error):

return 0, "", nil, Struct{}, nil may be written return _, _, _, _, _

return 0, "", nil, Struct{}, err may be written return return _, _, _, _, err

return 0, "", nil, Struct{X: Y}, nil may be written return _, _, _, Struct{X: Y}, _

return 1, "", nil, Struct{}, nil may be written return 1, _, _, _, _

return 1, "a", nil, Struct{}, nil may be written return 1, "a", _, _, _

return 1, "", nil, Struct{}, err may be written return 1, _, _, _, err

return 1, "a", nil, Struct{X: Y}, err may be written return 1, "a", _, Struct{X: Y}, err

@davecheney

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Aug 12, 2017

Contributor

When your functions has so many return values that typing them becomes a chore, that's a sign that you need to redesign your function, not the language.

Contributor

davecheney commented Aug 12, 2017

When your functions has so many return values that typing them becomes a chore, that's a sign that you need to redesign your function, not the language.

@mewmew

This comment has been minimized.

Show comment
Hide comment
@mewmew

mewmew Aug 12, 2017

Contributor

When your functions has so many return values that typing them becomes a chore, that's a sign that you need to redesign your function, not the language.

I think the example was given simply to provide a one of each function signature that is useful as a showcase. While not likely to see so many return values in real world code, returning the zero value of a struct using _ rather than image.Rectangle{} may improve readability; at least that's the idea of the proposal.

Contributor

mewmew commented Aug 12, 2017

When your functions has so many return values that typing them becomes a chore, that's a sign that you need to redesign your function, not the language.

I think the example was given simply to provide a one of each function signature that is useful as a showcase. While not likely to see so many return values in real world code, returning the zero value of a struct using _ rather than image.Rectangle{} may improve readability; at least that's the idea of the proposal.

@jimmyfrasche

This comment has been minimized.

Show comment
Hide comment
@jimmyfrasche

jimmyfrasche Aug 12, 2017

Member

@davecheney indeed.

My argument is that the primary benefit of the succinct syntax is that it improves the readability. If it makes it easier to type that's just a bonus.

If you see return ..., err you don't need to think about what else is being returned.

You don't need to double check for things that are suspiciously close to a zero value like return Struct{''}, err or return O, err or return nil, err (when nil has been shadowed for some reason).

It's immediately obvious that the only relevant value is err. Idioms such as

if err != nil {
  return ..., err
}

can be pattern matched by your brain as a unit without having to actually inspect anything. I'm sure we all do that now with similar blocks that contain one or more zero value-like expression. It's bitten me once or twice when I was debugging and my eye glazed over something that looked too close to a zero value making it hard to spot the obvious problem (I of course do not admit publicly to being the person who shadowed nil . . .).

I'm fine with how it is, however. This is just a potential way to make it a little bit easier.

@mewmew yes this proposal is based on a comment from that proposal (see the History section). I don't particularly see the point of the generic zero value except in the case of returns. It would solve the same problem, of course.

(I would like to be able to use {} as the zero value of any struct when its type can be deduced from the rest of the statement.)

Member

jimmyfrasche commented Aug 12, 2017

@davecheney indeed.

My argument is that the primary benefit of the succinct syntax is that it improves the readability. If it makes it easier to type that's just a bonus.

If you see return ..., err you don't need to think about what else is being returned.

You don't need to double check for things that are suspiciously close to a zero value like return Struct{''}, err or return O, err or return nil, err (when nil has been shadowed for some reason).

It's immediately obvious that the only relevant value is err. Idioms such as

if err != nil {
  return ..., err
}

can be pattern matched by your brain as a unit without having to actually inspect anything. I'm sure we all do that now with similar blocks that contain one or more zero value-like expression. It's bitten me once or twice when I was debugging and my eye glazed over something that looked too close to a zero value making it hard to spot the obvious problem (I of course do not admit publicly to being the person who shadowed nil . . .).

I'm fine with how it is, however. This is just a potential way to make it a little bit easier.

@mewmew yes this proposal is based on a comment from that proposal (see the History section). I don't particularly see the point of the generic zero value except in the case of returns. It would solve the same problem, of course.

(I would like to be able to use {} as the zero value of any struct when its type can be deduced from the rest of the statement.)

@nigeltao

This comment has been minimized.

Show comment
Hide comment
@nigeltao

nigeltao Aug 20, 2017

Contributor

@davecheney sometimes it's not the number of return values, it's their struct-ness. Typing return image.Rectangle{}, err can be a chore. The image.Rectangle{} is the longest but also least important part of the line.

That said, this particular proposal is not the only way to sooth that chore, as the OP noted.

Contributor

nigeltao commented Aug 20, 2017

@davecheney sometimes it's not the number of return values, it's their struct-ness. Typing return image.Rectangle{}, err can be a chore. The image.Rectangle{} is the longest but also least important part of the line.

That said, this particular proposal is not the only way to sooth that chore, as the OP noted.

@golang golang locked and limited conversation to collaborators Aug 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.