We can't realistically remove the if keyword at this point. It would break too many existing Go programs and too much existing Go documentation.

Cloud you show an example?

I mean an example which is hard to be fixed by go fix.

If we replace the if keyword with the ? syntax, we'd also replace the else keyword with :.

Excessive simplicity may be a burden.

this is like ruby's meta programming feature

I agree on this:

Excessive simplicity may be a burden.

Running go fix won't fix the documentation.

I oppose.

@ianlancetaylor, how about keeping the if keyword, but making it optional? and also allow the new way?

About the documentation problem, the change on map printing in Go 1.12 also has the same issue.

Sure, we could just allow the new suggested approach. I was only pointing out that we can't realistically remove the if keyword. That's just not going to happen.

The change to map printing affected fewer people than removing a key element of the language like if, by several orders of magnitude. And the change did not invalidate any existing code, it just changed it to always use a specific order where before it used an unpredictable order. It's really not the same kind of thing at all.

@rocket049 Thanks for the note. I encourage you to either explain your position, or just use the emojis on the first comment to express your opinion. Please see https://golang.org/wiki/NoPlusOne , although in this case I guess it's really NoMinusOne. Thanks.

Note that if

x? {
    ...
}

is equivalent to

if x != zero-value-of-x {
    ...
}

then values of type error and values of type bool will behave somewhat differently. For a value of type error the block will be executed if there is an error. For values of type bool the block will be executed if the value is true. That is, with the typical meanings of those values, in one case we will execute the block if there is a problem, and in the other case we will execute the block if things are OK. This could be acceptable, but it's worth considering.

This is very interesting. I like the idea of having one way to know if any type is a zero value or nil.

I would probably prefer a built-in function called isZero() that could work on any type. It does not improve error boilerplate but simplifies other if statements and remove functions like time.Time{}.IsZero().

In the upcoming 1.13 release we do have reflect.Value.IsZero (https://tip.golang.org/pkg/reflect/#Value.IsZero). Definitely more awkward to use than a builtin function.

@ianlancetaylor reflect.IsZero sounds helpful. I would probably use it more if it wasn't inside the reflect package. I try to follow The Laws of Reflection which says

It's a powerful tool that should be used with care and avoided unless strictly necessary.

if statement must follow by a bool.

The err?, err?? or err?! breaks the convention of if statement.

I'll be honest, I'd rather have ternary.

I would already be happy with making either nil falsy everywhere oder just for the error type.

if err { return err}

This would already remove most of the error checking boilerplate and is very simple and straight forward.
Go format can in addition force it to be in one line.

Even this would be simpler to write but not harder to read:

if err := Foo(); err { return err}

This proposal does not add anything to the language we cannot already do. And it's not all that much shorter. And it's potentially confusing. And it has very little support. Therefore, this is a likely decline. Leaving open for four weeks for final comments.

There were no further comments.