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

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.

@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?

@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?

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?

@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.

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

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.

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.

@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.)

@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.

Reopening per discussion in #33152.

I am in favor of allowing only the return ..., x form. If other forms are good, they could be added later.

The main benefit of this for me is that it would let me use a dumb macro to expand ife into

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

Yes, a sufficiently smart IDE macro could look at the function return arguments to fill those in for me, but why not just simplify it so only the important information is emphasized?

What about letting return take 1 thing regardless of how many results the func has, as long as the assignment is unambiguous to exactly 1 of the return types?

So:

    func foo() (*T, error) {
        if fail {
             return errors.New("foo")
        }
        return new(T)       
    }

Does anybody see any problems with this language change?

We think we should consider just the simple case: return ..., val1, val2 where val1 and val2 become the final results of the function. Typically, of course, this would be just return ..., err. The other cases don't seem to arise enough to worry about. This would only be permitted if there are other results; it could not be used in a function that returns only error. The omitted results would be set to the zero value, even if the result parameters are named and currently set to some non-zero value.

-- for @golang/proposal-review

@bradfitz that seems like it could cause too much fun when the return signature changes in a long func or one of the return types now satisfies an interface. It would also be unusable with interface{}, though that's a bit niche.

It would also be unusable with interface{}, though that's a bit niche.

That's a feature.

@zephyrtronium nice suggestion:return zero..., err would satisfy the use case of "I just want to return an error" equally well.

However, I don't think we want to blur the semantics of x...- it currently expects x to be an array.

It would kind of make sense to use both dot forms at once! return (...zero)..., err where ...zero used at the value level means an array of zero values just as ...param means an array of type param at the type level. return x... would work similar to the existing Go ... to expand the array, but also set the length. But I don't think constructing arrays with ...x is that useful otherwise, and anyways that's too many dots for my taste!

Another approach would be to pre-define an array of zeros as zeros, so we would have return zeros.... But again, I don't think zeros would be very useful outside of this use case.

I opened a proposal to not require ... and instead just allow return err when there are multiple return values. I think this new proposal makes sense and avoids bike-shedding about several things in this proposal. At least this new form will seem significantly better or worse to some, so it seemed worthy or a separate proposal. I don't care what solution we come up with as long as Go will let me just return an error :)

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

If you have a function with things like

return 0, time.Time{}, nil, err

then the original proposal would let you write

return ..., err

which is admittedly much nicer, especially when you decide that third result wasn't needed and don't have to update all the return statements to drop the ", nil".

The "zero" suggestion doesn't help as much:

return zero, zero, zero, err

still has to get updated.

If you have a function with things like

return 0, time.Time{}, nil, err

I looked through the discussion above and haven't noticed if we attempted to survey the existing corpus of Go code, for if such function is that widely used, so it's worth overloading the ... and adding a new meaning to the construction.

My, very naive, guess is that functions like below are what dominate, and cause the main unsatisfaction

// 1
return SomeStruct{}, err

// 2
return SomeStruct{}, false

With that, IMHO, allowing return _, _ would solve the majority of the annoying cases.

Placing on hold for more thought and later discussion.

Placed on hold.
— rsc for the proposal review group

Any updates? I am still hoping for this any of these changes to make the return boilerplate inside an if err != nil cleaner. I have sometimes returned a *Struct{} instead of Struct{} so my returns can all be nil, err but that is a misuse.

To summarize the whole conversation:

The problem is with a return type that has multiple returns like (package.Struct{}, bool, error). Which is distracting to both type and read when a function has many error checks that end up looking like this.

if err != nil {
    return package.Struct{}, false, err
}

The original proposal was to allow ..., followed by any values.

return ..., err

Discussions on this on this included allowing ..., true, nil, the opposite package.Struct{}, ..., an empty .... The issue revealed is that it would make sense to allow ..., true, ... but that would be impossible for the compiler if there were multiple of the same return type in the middle like (any, any, any, error).

That led to the discussion of allowing zero value in the returns. Either as

return _, _, err

Or create a new Go builtin zero, like these other proposals #35966 and #52307. The zero would work as any zero value. Separating it from _ avoids confusion for people and the compiler.

return zero, zero, err

The complaint with a zero is if your return signature changes all the error lines also need to change.

I would be happy with any of them! I personally like the zero builtin because I would also use it in table unit testing.

I have sometimes returned a *Struct{} instead of Struct{} so my returns can all be nil, err but that is a misuse.

I was guilty of that last week as well. 😅

Considering only the beginning and end, not the middle part may be more appropriate

resut,...
resut1,resut2,...
...,err
...,msg,err

Something I didn't see any mention for was the pain of refactoring all the return error statements when a complex function with multiple return values requires changing the list of its return types (add or remove return elements). This proposal significantly simplifies this process.

I am fan of the ..., err syntax. That being said, I believe @narqo's comment is true. Most cases we are dealing with two values being returned, and _, err would be sufficient.

Either way, I would love to see this issue move forward!

@Nasfame I personally think named returns are great for documentation but the amount of shadow variables they cause with := inside of ifs and fors makes using naked returns dangerous and cause more bugs than are worth the trade-off.

@Nasfame I agree that the tooling, especially linters, has gotten much better. My issue is like you said, you needed "extensive usage over time" to prevent the bugs. I have coworkers who don't install all the tools in vim or are just new to Go. I don't like "naked returns" because it means I have to be constantly vigilant in my code reviews for a bug that wouldn't exist if you just didn't use them.

Bringing this up again.
I'm personally in favor of the _ overload for several reasons.

• Ellipsis is more associated with the spread operator in programming languages (such as our dear Go) while on the other hand, the underscore is usually used as ignore/skip/don't care. it feels more natural to me for this usecase.
• Ellipsis is 3 characters, underscore is one!
• Less complex to implement (how many - and where - ellipsis are allowed in a return statements)

What ellipsis offers is being able to skip multiple return values together, but let's face it: if you have functions with +3 return values, you have much bigger problems than the extra typing needed for returns. %99 of legit Go code I've seen returned either a single value, a value and an error, or in rare cases, two values and an error. And I can say that the latter case has almost always been the result of a rushed change or a lazy programmer.

For the underscore proposal, I also suggest preventing return _, _, a return statement (with the exception of no-return functions obviosly) must have at least one non-blank value. Returning "nothing" from a function that returns values is always a mistake because the caller is expecting "something" from you. Caller should have means to differentiate between intended zero values and skipped zero values. That's what the error does: if err is nil, then the value is intended even if it's zero. if err is non-nil, then the value should be discarded even if it's non-zero. _ should only be used as don't care, not zero. Otherwise it's a misuse.

Having said that, what about defining the behavior of _ as returning "some" value with the corresponding type? The initial implementation may be in fact zero, but by not guaranteeing a zero value we can prevent the misuse. And this may even enable some optimizations in the compiler. e.i when an underscore is returned, compiler can save some CPU cycles from unnecessary zeroing out bytes in the return segment of the stackframe and just let the caller get whatever value's already in there?

I would like to suggest using any... for returning multiple, consecutive zero values.

As @vispariana mentioned, the ... is more related to the spread operator. We could take advantage of this fact to spread the any keyword into multiple any values.

This has the advantage of being familiar syntax, and more readable for newcomers.

Examples:

return any..., err
return true, any..., err
return x, any...

By allowing only 1 instance of any... in a return statement, we ensure that the replacement is unambiguous.

@lorena-mv any outside of type constraints is equivalent to interface{} which would imply a conversion to an interface. True consistency would probably be something like

return [T any]T[]{...}..., err

which could perhaps be shortened to something like

return [any]..., err

Where this can potentially be generalized to allow the writing of a type in a return statement to give the zero value of that type as the return value (and ellipsis will return multiple of that value).

I think though that this is all more confusing than other alternatives already given here.

We have seen in this thread _ and ... but I don' think actually both. Here is a variation to support both:

return _, err // 1 value in addition to `err`
return _, _, err // 2 values in addition to `err`
return _..., err // any number of values in addition to `err`

Hey @rsc , do you know if there is a plan to proceed with this proposal?

The proposal is on hold. It would need to come off hold and be approved by the Go proposal review team.

The proposal is on hold. It would need to come off hold and be approved by the Go proposal review team.

I would like to know if there are more details on why this was put on hold last time, and if there are any plans to take it off hold again?

@vispariana it requires to insersect several language features so it went on hold for more thoughts.
For instance, #66651, if accepted (and possibly extended to accept multiple variadic type parameters), could be used as-is or to implement such feature.