This would make it too easy to accidentally confuse ok bool results with error results. Today, the lack of == nil suffix distinguishes them on the caller side, making it easier to spot bugs like this one:
https://play.golang.org/p/XUfXSi1w8Mf

This would make it too easy to accidentally confuse ok bool results with error results. Today, the lack of == nil suffix distinguishes them on the caller side, making it easier to spot bugs like this one:
https://play.golang.org/p/XUfXSi1w8Mf

I think this wouldn't be too confusing because most of the time instead of ok bool you do err error i haven't seen ok error to this day and it would simplify the language when if err != nil is a really big occurrence in go

@Terottaja, if the caller mistakenly writes x, ok := […] instead of x, err := […], today that is obvious because the if ok check produces a compile-time error. Under your proposal, that would no longer be a compiler-time error, because if ok would be valid even if the variable ok has type error.

This looks like a duplicate of #21769, which was declined.

@Terottaja, if the caller mistakenly writes x, ok := […] instead of x, err := […], today that is obvious because the if ok check produces a compile-time error. Under your proposal, that would no longer be a compiler-time error, because if ok would be valid even if the variable ok has type error.

Seems like that definitely could be done, But could be also evaluated because usually people don't write ok error

Is it really worth losing the explicitness of if err != nil { for if err.

I would rather have the ! operator work on errors like it does in Javascript or Ruby where a !! can mean != nil because ! turns anything into a boolean.

That would make if err != nil become if !!err { . It is hard to understand at first, but it would keep the language explicit.

The if statement should accept a bool. It seems like converting err to a bool implicitly.

if !err? {}
if !?err {}

They reduce readability.

I have to agree with @mvndaai that this proposal risks diluting the clarity of the language and making it behave more like ECMAScript (JavaScript). I really don't think it should go in that direction. However, if a special operator like the !! from Ruby were used that would make it clearer. I'm still not completely in favor of that operator though, but it is better than not specifying anything.

I have to agree with @mvndaai that this proposal risks diluting the clarity of the language and making it behave more like ECMAScript (JavaScript). I really don't think it should go in that direction. However, if a special operator like the !! from Ruby were used that would make it clearer. I'm still not completely in favor of that operator though, but it is better than not specifying anything.

could also use ? since its not being used anywhere else

@Terottaja the ? symbol is a good possibility. It is already used to denote null-safe dereference in C# so it could make sense for a short-hand nil check in Go.

How do you propose the syntax would look? prefix or postfix?

Also, the only other situation that needs to be made clear is how to use the not nil check for a nil check and have it look sane.

Should this support operator inversion and how.

@Terottaja the ? symbol is a good possibility. It is already used to denote null-safe dereference in C# so it could make sense for a short-hand nil check in Go.

How do you propose the syntax would look? prefix or postfix?
i think both could work, i think personally prefix because ! and soon to keep consistency.

If it is readability you are after, you could consider to add a private has() function to your package:

func has(i interface{}) bool {
	return i != nil
}

You can then rewrite your example like:

if has(err) {
	panic("Error occurred")
}
	
// or

if r := result; has(r) {
	print("Result: ", r.Text)
}

Like: https://play.golang.org/p/MSBQbytsi61

Obvious downside is that you have to redeclare the 'has' function in every package where you need it.

The has() function doesn't reduce the code any not that reducing typing was the goal, but clarity it has().

So, first revised proposed syntax:

if ?err {
    panic("Error occurred.")
}

Votes please.

or second revised proposed syntax:

if err? {
    panic("Error occurred.")
}

Votes please.

This seems like a dup of #32845 and #33152.

This seems like a dup of #32845 and #33152.

Closing

@Terottaja why was #32845 closed, but #33152 kept open which is newer and this one closed. Not sure what is going on. I would reopen #32845 and close the rest.

Or split up #33152 since it contains several issues in one.

I wouldn't say that #33152 is being kept open as such. I would say that we haven't gotten to it yet.