proposal: improved nil checking

[LUC18fknU7P]

What version of Go are you using (go version)?

1.10.3 windows/amd64

What operating system and processor architecture are you using (go env)?

win 8.1 amd64

go env Output

C:\Users\Administrator>go env
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\Administrator\go
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\ADMINI~1\AppData\Local\Temp\go-build237241822=/tmp/go-build -gno-record-gcc-switches

Proposal for C Style nil checking

Instead of

if err != nil {
    panic("Error occurred")
}
// or
if r := result; r != nil {
    print("Result: ", r.Text)
}

you could write

if err { // err is a valid interface and not nil
    panic("Error occurred")
}
// and

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

i think this would free up a lot of if err != nil clutter kind of how for {} is and also if statements with multiple nil checks and that this would be great with having to write less and being more productive with Go. If anyone has any better ideas i would like to hear them too to hopefully improve Go as the language evolves and this could be even applied to any other type if they can be nil

[bcmills]

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

[LUC18fknU7P]

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

[bcmills]

@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.

[ccbrown]

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

[LUC18fknU7P]

@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

[mvndaai]

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.

[donaldnevermore]

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

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

They reduce readability.

[jcoder76]

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.

[LUC18fknU7P]

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