[RedNifre]

(I'm not a Go programmer)

I find this a bit odd. Isn't the idea of the primitive error handling that it is obvious and easy, as in "functions can return multiple results, a popular pattern is to return the good result and the error as two separate nullable values of which exactly one will be not null, so you can check if err == nil."?

If you go with fancy error handling anyway, how is this '?' better than returning a Result and do something like foo().getOr { return fmt.Errorf("Tja: %v", err) }

[pornel]

The ? syntax agrees that errors should just be regular values returned from functions, and handling of errors should be locally explicit. It's not a different approach from `if err != nil return err`, it merely codifies the existing practice, and makes expressing the most common cases more convenient and clearer.

It's clearer because when you see ? you know it's returning the error in the standard way, and it can't be some subtly different variation (like checking err, but returning err2 or a non-nil ok value). The code around it also becomes clearer, because you can see the happy path that isn't chopped up by error branches, so you get high signal to noise ratio, fewer variables in the scope, without losing the error handling.

[RedNifre]

I think what I meant is that out of these three ways to do it, I don't like the second one:

1. The language has the feature of returning multiple values, which is then used in an error handling pattern.

2. The proposal is about special syntax for that pattern

3. Languages that have generics (like Go) can instead implement a Result type, turning this pattern into more readable code without the extra syntax.

I feel like a Result type would have more advantages and be less disruptive than a syntax macro for a pattern, but I'm not sure.