proposal: Go 2: on err { statement } and return!

[sirkon]

Example:

file := os.Open(fileName) on err {
    return! errors.Wrap(err, "open config file")
}

1. here <vars> := A on <var> { … } is an equivalent for

   <vars>, <var> := A
   if <var> != nil {
       …
   }
   

   where <var> must implement error.

2. return! is a shortcut for return statements with error. It substitutes first values with their type zeroes and the last value must be an error. Example:

func F() (string, error) {
    return! errors.New("error")
}

is an equivalent for

func F() (string, error) {
    return "", errors.New("error")
}

So, the first example is an equivalent for (inside the function returning (*os.File, error))

file, err := os.Open(fileName)
if err != nil {
    return nil, errors.Wrap(err, "open config file")
}

Pros:

1. No magic
2. This construct can be used to move slowly to stricter error handling. Mandatory on, for instance. I mean this method will work with sum-types as well.

Cons:

1. It looks like there can be a clashing with named return values

[ianlancetaylor]

The on err part of this looks very similar to #32946 and others.

The return! parse of this looks very similar to #33152.

[sirkon]

The on err part of this looks very similar to #32946 and others.

The fact an error variable is explicitly mentioned outside in the same line makes it not very similar I guess. That onErr is a bit too magical.

The return! parse of this looks very similar to #33152.

Yes, sure. The difference I proposed new keyword for such kind of returns, not the change of regular return

[urandom]

Also: #33029

[donaldnevermore]

The on part is fine to me. However, the return! looks wierd because I don't know what it means at first sight and I don't want a strange rule to remember.

[RmbRT]

This is an anti-pattern: It's not backward compatible. Old code would suddenly no longer work, because return!value is a valid Go 1 syntax.

[sirkon]

This is an anti-pattern: It's not backward compatible. Old code would suddenly no longer work, because return!value is a valid Go 1 syntax.

return? then. And expr on err → expr or err, i.e. or instead of on: may work as nil handling. The more I look at this proposal (I am a starter) the more I like it. Modified one:

file := os.Open(filename) or err {
    log.Error().Err(err).Msg("file not found, fallback to stdin")
    issue os.Stdin // file becomes os.Stdin if failed to open filename
}

file := os.Open(filename) or err {
    return? errors.Wrap(err, "opening config file")
}

var absPathFor map[string]string
…
absPath := absPathFor[relPath] or {
    return? errors.New("no absolute path found for " + relPath)
}

I.e. this extended or would work for both types with error and nilable types. And the shortcut can be introduced:

func Function(…) !(type₁, type₂, …, typeₙ) = func Function(…) (type₁, type₂, …, typeₙ, error)

The implicit error except the case of

func Function(…) error