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

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

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

Also: #33029

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.

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.

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