Second point looks good

The ? part of this proposal looks essentially the same as #32845.

Didn't see that issue. I've seen proposals to allow return _, err (although I can't find an issue ATM), but not return .... The difference between return _ and return ... is that ... would return as many values as necessary, not just one, so it could be used in any function with an error return.

I was going to open an issue to propose the same thing as the 2nd point.

I see two main benefits of this:

1. It is a pain to have to write the zero values explicitly while they don't carry any meaning anyway because it is an error return
2. If you change the signature of the function, you often have to change multiple lines because you have multiple error returns

This proposal solves both issues beautifully.

Compare

func before() (bool, string, MyStruct, error) {
    return false, "", MyStruct{}, errors.New("error")
}

func after() (bool, string, MyStruct, error) {
    return ..., errors.New("error")
}

Let's throw the "ellipsis" keyword here so that this issue can be found more easily, because I think that's what "..." is commonly called.

Also, if #21291 passes, this could be used to return explicitly "all-zeros" with return ...

Hey, thanks for the proposal.
But I'm having issues with understanding what value it brings.
Both options, conceptually do not bring any solutions to the problem. They just save few characters that you have to type. It feels more like a workaround than a solid solution.

They just save few characters that you have to type.

Yes, I have come to the conclusion that apart from try(), saving a few characters is all that is possible, because all the other proposals end up reinventing if and defer with non-orthogonally different semantics.

My gut feeling says that maybe it’s too early to solve this “problem” with the current state of the language.
Probably, we need new language constructions for a better solution. (Pattern matching, for example)
I would encourage the community to put it on hold and focus on other parts of the language.

IMO those are 2 different proposals, for example I really like the ..., err part but absolutely hate the first.

Isn't named return values an alternate solution for ellipsis?

func aFunction() (a int, b string, c bool, err error) {
  if er := someCall(); er != nil {
    // Should be aware not to shadow return params
    err = fmt.Errorf("Error: %v", er)
    return
  }

  ...
}

We don't have to explicitly return the zero values each time this way. They are auto populated at function start.
If the naked return affects the readability, we can even use

return a, b, c, err

Named values may have been set and not zero. Depending on the function, that matters. Also they can't be used in all (or even most?) functions, which makes it inappropriate for an editor macro.

A lot of times, it is needed to return whatever values are set when some error occurs. Just because an error occurs doesn't mean you should always return zero values for other return parameters.

The calling code may inspect this error and take necessary action using the "intermediate" result.
The best example would be io.Reader, when an EOF occurs. Underlying implementation may return read bytes and also an error.
So using named values solves both these problems (zero values or intermediate values).

I wonder why it cannot be used in most functions.

io.Reader/Writer is the exception that proves the rule. Almost nothing else can return both an error and a result. It's pretty much one or other. IO is different because it is possible to do a partial read/write and still get meaningful results, but there's no such thing as half an HTTP response header or half a decompressed file.

Let's throw the "ellipsis" keyword here so that this issue can be found more easily, because I think that's what "..." is commonly called.

Also "variadic return"

@carlmjohnson I love the return ..., err it might be worth making a separate proposal just for it.

The if statement is like

if <bool> {
        ...
}

Looks like err? returns a bool. I think using ? to replace !=nil doesn't solve the error handling problem at all.

why not just
r := os.Open(src)?

@nigeltao in 2012: https://groups.google.com/forum/#!msg/golang-dev/iAysKGpniLw/qSbtBUx4-sMJ

An alternative proposal is to make _ more like /dev/zero than /dev/null:

var x struct{} = _
var y int = _
func f() (bool, string, io.Reader) {


  c := make(chan struct{}, 99)
  c <- _
  return _, _, _
}

The first part of this proposal, using ? to mean != <zero value>, is a duplicate of #32845, which is closed.

I suggest that someone open a new issue to focus only on the return idea, and that when that is done we can close this issue in favor of those two.

@ianlancetaylor There's #21182 for ... in return. I retracted it, but don't mind if it's reopened. I closed it in favor of #19642 which is the issue for _ as a universal zero value

@jimmyfrasche Thanks. I reopened #21182.

Closing this issue as a dup of #21182 and #32845.