Please fill out https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing language changes

What's the expected behavior of the snippet below? (adapted from your proposal)

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, err := Marshal(v)
        var buf bytes.Buffer
        err = Indent(&buf, b, prefix, indent)
        return buf.Bytes(), err
}

What's the expected behavior of the snippet below? (adapted from your proposal)

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, err := Marshal(v)
        var buf bytes.Buffer
        err = Indent(&buf, b, prefix, indent)
        return buf.Bytes(), err
}

The compiler will not complain the above code as an error due to unused error variables and will generate code with same semantics as the original code.

What does this generate?

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, err := Marshal(v)
        foo(err)
        return b, nil
}

This change is not backward compatible.

Code like this is valid today, but would change behavior under this proposal.

        b, err := Marshal(v)
        err = F()
        return err

A possible solution to this would be to tell the compiler where it should generate the returns.
Taking inspiration from rust the code would look something like this instead:
(the ? question mark would indicate an early return)

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, _ := Marshal(v)?
        var buf bytes.Buffer
        Indent(&buf, b, prefix, indent)?
        return buf.Bytes(), nil
}

Correct me if I'm wrong but this would not break existing code I don't think?

see #51146

Thanks for pointing me in the right direction @seankhliao.

Nothing new under the sun ☀️ 😹

What does this generate?

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, err := Marshal(v)
        foo(err)
        return b, nil
}

This won't change anything as err value is used by foo.

This change is not backward compatible.

Code like this is valid today, but would change behavior under this proposal.

        b, err := Marshal(v)
        err = F()
        return err

Yes, thanks, the behavior is changed for this code. It was overlooked.
Some workarounds possible to add hints to compiler? Think of some but not very ideal. Throw a sprat below.

1. Add go directive like //go:autoerrorhandling at file level. Seems lightweight, but still not natural enough not to set by default.
2. Use go.mod directives. Shortage: setup burden.
3. Rename new files with extension to .go2. Shortage: affect too many tools

I want to be clear that we aren't going to do any of those things. Breaking compatibility with existing code is a huge cost. It would require a huge benefit. This suggestion is at best a small benefit, not nearly sufficient to break compatibility.

A possible solution to this would be to tell the compiler where it should generate the returns. Taking inspiration from rust the code would look something like this instead: (the ? question mark would indicate an early return)

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, _ := Marshal(v)?
        var buf bytes.Buffer
        Indent(&buf, b, prefix, indent)?
        return buf.Bytes(), nil
}

Correct me if I'm wrong but this would not break existing code I don't think?

I have a similar idea.

func foo()error{
         res, err? := bar() defer handleMore(err)
}

It is equivalent to:

func foo()error{
         res, err := bar()
         if err!=nil{
                  defer handleMore(err)
                  return err
         }
}

It is simple, explicit, and extends defer to handle additional tasks before returning.

see #36390

A significant change in semantics based on whether or not a variable is used is too confusing for a language like Go.

The later suggestion of a ? has been made before as @seankhliao points out.

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

A possible solution to this would be to tell the compiler where it should generate the returns. Taking inspiration from rust the code would look something like this instead: (the ? question mark would indicate an early return)

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, _ := Marshal(v)?
        var buf bytes.Buffer
        Indent(&buf, b, prefix, indent)?
        return buf.Bytes(), nil
}

Correct me if I'm wrong but this would not break existing code I don't think?

I have a similar idea.

func foo()error{
         res, err? := bar() defer handleMore(err)
}

It is equivalent to:

func foo()error{
         res, err := bar()
         if err!=nil{
                  defer handleMore(err)
                  return err
         }
}

It is simple, explicit, and extends defer to handle additional tasks before returning.

multiple returns

func foo() (any, error){
    res, (nil, err)? := bar()
}

or

func foo() (any, error){
    res, carry (nil, err) := bar()
}

@senluowx It seems unnecessary to complicate things further. I know that my plan is not accepted and the reason, but I still want to explain. Some previous issues (such as #37174 ) mentioned only returning an error, and others using the default zero value in go, such as the case you mentioned. So my idea mentions extending defer, because if you just simplify return, you can't handle some extra operations before return only when errors occur, and if there is a non-zero value that needs to be returned, you can assign a value after defer in the way of a named return value.

I had an idea to extend original suggestion by re-using the existing keyword "return" as modifier to the error var to be managed. i.e.,

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, err := Marshal(v)
        if err != nil {
                return nil, err
        }
        var buf bytes.Buffer
        err = Indent(&buf, b, prefix, indent)
        if err != nil {
                return nil, err
        }
        return buf.Bytes(), nil
}

becomes

func MarshalIndent(v any, prefix, indent string) ([]byte, error) {
        b, return err := Marshal(v)
        var buf bytes.Buffer
        return err = Indent(&buf, b, prefix, indent)
        return buf.Bytes(), nil
}

It keeps the backward compatibility as "return var" as a left-value won't be conflict with existing code, and the original keyword return exists in different context from current one which is in a left-value.

Without "return" modifier, the err value would be handled in old familiar way.

Also "return" can be used for any number of error variables. So that compiler will handle it one by one according to text order. e.g.,

return err1, return err2, a, b, err := f(c, d)
will be corresponding to

err1, err2, a, b, err := f(c, d)
if err1 != nil {
   return _, err1
}
if err2 != nil {
   return _, err2
}

For me it has less mental burden to use "return" modifier than any other cryptic symbols (like ?, or !) or new keywords/func(check, try) and it still looks like normal go code. The "return" keyword looks like compressing if err statement{return _, err} into a single keyword "return", which is a natural reminder of a control flow exists here: if the error value is not nil, it will be handled automatically by compiler.

But I am not sure if the idea falls into existing bad cases or others may feel strange. Welcome comments. Thanks.

PS:
Found that it was similar to this declined issue, which uses a new keyword "check" in the place of "return" here #46655

Another issue suggesting "pass err", and even "return? err" or "return if err" #37141

No change in consensus.