please leave the "if err != nil" alone !

Similar to #33029.

I don't get this one:

major, minor := http.ParseHTTPVersion("http1.1") ?ok os.Exit(1)

In the examples with err ?err means something like "run the next statement if err != nil". In this example, it seems to mean "run the next statement if !ok". That is, for err it runs the statement if the last result is not the zero value of its type, but for ok it runs the statement if the last result is the zero value of its type. What is the exact rule here?

I don't get this one:

major, minor := http.ParseHTTPVersion("http1.1") ?ok os.Exit(1)

In the examples with err ?err means something like "run the next statement if err != nil". In this example, it seems to mean "run the next statement if !ok". That is, for err it runs the statement if the last result is not the zero value of its type, but for ok it runs the statement if the last result is the zero value of its type. What is the exact rule here?

@ianlancetaylor
Sorry, actually, here is !ok,
! means:
assert(var != )
if failed, then execute the short circuit logic.

? means:
assert(var == )
if failed, then execute the short circuit logic.

major, minor := http.ParseHTTPVersion("http1.1") !ok os.Exit(1)

@AllenYN

please leave the "if err != nil" alone !

There are a number of error handling proposals out there, such as check/try/catch, that are heavily modified at the language level or look ugly. I think the error returned by each expression should be taken seriously and should not be changed, but there is a real need to reduce if err != nil { }, It's too ugly, or there wouldn't be so much controversy😀

@ianlancetaylor
yes, it's similar to #33029. But I want to solve the problem from the perspective of optimizing multi-return value processing. Generally, when multiple values are returned, the last one usually carries the control information. when !ok or err != nil, the workflow is usually break or fix. so maybe it's not bad for adding some syntax sugar for quick break or fix without affecting the main workflow.

I love that the err variable doesn't need to live outside of when it should be handled.

I am concerned that inlining the handling would make it harder to know the flow of a function.
Would you be okay with gofmt formatting it like this?

r := os.Open(src) ?err {
    return err
}

Which would keep the ability to ignore indented code on a first pass of reading a function. See Mat Ryer's presentation on why he avoids else.

The problem is not about err != nil. The problem is about error handling. The ?err is not clear as err != nil.

r := os.Open(src) ?err {
    return err
}

@mvndaai yeah, maybe it looks confusing.
But I think the key of ?<variable> is simplify handling of multiple-return-values. The statements behinds ?<variable> I call it short-circuit-logic which is usually break or fix current workflow, so it could be ok if only supporting one single (line) function, like:

// return err
r := os.Open(src) ?err return nil, err
// handle err
r := os.Open(src) ?err handle(err)
// handle then return
r := os.Open(src) ?err return nil, handle(err)
// example
io.Copy(w, r) ?err return nil, os.Remove(dst)

This is basically #33029 with a slightly different syntax. This doesn't seem to bring any new functionality beyond that issue. This does not have strong support. Therefore, this is a likely decline. Leaving open for four weeks for further comments.