IMHO it will be hard to come with a reasonable construct that handles and map the error that is clearer than if err != nil {// map it and possibly return it}.

However there are situations where you don't want to do anything with the error, but return it. Ex: if getData in the proposal already adds the context info to the error it returns, add stack trace and so on, you might just want to return it. This could be

func foo() (*Data, error) {
	data := getData()?           // or getData()! or something else 
	doSomething(data)
	return data, nil
}

that will be the equivalent of

func foo() (*Data, error) {
        // num of vars `getData` returns + err
        // |                                    num of vars (zero value) `foo` returns + err
        // |                                             |
        _v1, _err := getData(); if _err != nil { return nil, _err }; data := _v1
	doSomething(data)
	return data, nil
}

Basically the new syntax would be used only when you write ..., err := somethingThatErrors(); if err != nil { return ... ,err }
Most probably something like this has already been proposed, or is a comment to one of many proposals, sorry for repeating.
I agree with the title of this issue, but not with what is proposed.

(I'd like a proposal with error-non-handling tag)

I'm understanding this proposal as adding a new ternary operator that takes three operands:

1. An expression whose final result value is of type error.
2. A symbol name that acts as a local variable of type error in the third operand.
3. An expression whose results are assignable to the return values of the enclosing function.

The evaluation process would then be:

1. Evaluate the expression in operand 1.
2. If the final error result from that expression is nil, immediately return all of the other return values (if any), discarding the final error one, and terminate.
3. Otherwise, assign the error result to the symbol given in operand 2, and then evaluate the expression in operand 3 with that symbol in scope. Assign its results to the function return values, and then immediately return from the enclosing function.

Please correct me if I misunderstood. 😀 The rest of what I wrote in this comment probably won't make sense if I didn't understand correctly.

This does seem plausible in principle, but I think my main reservations are about the specific syntax you chose here:

• It resembles the ternary conditional operator in C and many of its descendants, but has a very different meaning.

  Since Go is quite "C-like" in various other ways, I expect someone new to Go but familiar with another language in the C family would initially assume this was a ternary conditional, rather than assuming it's a new language construct that they need to learn about.

• I can't think of other places in the language where a sequence like symbol : expr introduces a local scope with an additional symbol inside it. That doesn't necessarily mean this couldn't be the first, but I think it would be preferable for this to resemble something else that's already familiar in the language, and ideally something that makes it clear which parts of the program have that err symbol in scope.

  One possible alternative could be: expr ? (err) { return expr }, which I wrote to resemble the function declaration syntax but without the func in front. However, this form does seem to imply that the part in { } is a normal block, in which case it would also support multiple statements and support not returning, which makes this considerably more general than your proposal.

  data := getData() ? (err) {
      return nil, errors.Wrap(err, "failed to get data")
  }

  If I were reviewing what I just proposed, I would immediately become skeptical about how much of an improvement it is over the original if statement approach -- it only really saves one line, now -- so I don't think this alternative is super compelling. Maybe others have better ideas.

A further random question, that doesn't really fit in the above list:

• How does this generalize for functions that don't return an error, or even weirdo functions that might return more than one error for some reason?

  One way I could imagine specifying it is that the second operand can have multiple symbols separated by commas, up a maximum of the number of return values from the expression in operand 1. Each declared symbol would consume one of the trailing return values from the expression, and so the result of the operand in the non-error case is whatever results are left after all that consuming.

  Concretely: foo() ? a, b : ... would work as long as foo has at least two return values. If it has exactly two return values then this overall expression returns no results. If it has three return values then the overall expression has one result -- the first one -- and the other two get assigned to a and b respectively.

  However, this of course now complicates the matter of what the implied condition is for deciding whether to return or continue. Does it return early unless all of the specified symbols have their zero value assigned to them?

  It might also be reasonable to say that it's a compile-time error if the final return value isn't of type error, and that only one symbol is allowed and it's always of type error, and that in all other cases authors must use the traditional explicit if statement. That's not really an orthogonal design, but I do accept that any part of the language that's focused specifically on error handling is likely to be non-orthogonal, and indeed it's the classic debate in all of these proposals about whether the language should have non-orthogonal features focused specifically on error handling, rather than treating error handling as "normal code".

I still like the try getData() syntax much more as we don't have that many postfix operators aside from ++

Based on the discussion above, and the emoji voting, this is a likely decline. Leaving open for four weeks for final comments.

No further comments.