Proposal: use a value other than nil for uninitialized interfaces

[pcostanza]

It's confusing that nil can be used both as a value to represent an uninitialized interface, and as a value for the pointer that an interface is initialized with. It's also very inconvenient to determine whether a pointer value in an interface is nil without casting it to the pointer type.

Proposal: use a value other than nil for uninitialized interfaces. To avoid adding new pre-defined identifiers, the value could be syntactically represented as {}, for example. This would allow expressing tests like this:

var v interface{}
...
if (v != {}) && (v != nil) {
   ...
}

The test against nil then doesn't need a cast and doesn't need to use the reflect package.

[davecheney]

My counter proposal is remove the "typed nil" scenario I wrote about here https://dave.cheney.net/2017/08/09/typed-nils-in-go-2 by making an nil interface and an interface which contains a type who's value is nil also equal to nil.

…

On Sat, 19 Aug 2017, 23:57 pcostanza ***@***.***> wrote: It's confusing that nil can be used both as a value to represent an uninitialized interface, and as a value for the pointer that an interface is initialized with. It's also very inconvenient to determine whether a pointer value in an interface is nil without casting it to the pointer type. Proposal: use a value other than nil for uninitialized interfaces. To avoid adding new pre-defined identifiers, the value could be syntactically represented as {}, for example. This would allow expressing tests like this: var v interface{} ... if (v != {}) && (v != nil) { ... } The test against nil then doesn't need a cast and doesn't need to use the reflect package. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21538>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcAzr7lMeaS7v8emB6WoaD9HJHo1Xoks5sZunDgaJpZM4O8Vxm> .

[pcostanza]

i == nil being true both when the interface is uninitialized as well as when it's initialized with a nil pointer would require implicitly compiling the code to two tests rather than one. My suggestion would more directly maintain a correspondence between how many tests are expressed in the source code and how many tests the source code is being compiled to.

Also, your suggestion would require special handling in case you need to distinguish the two cases, through some additional constructs either as part of the language, or through some additional functions in the reflect package, for example. With my approach, you always have to distinguish the two cases, similar to what you already have to do now.

I'm not saying my approach is better than yours, or vice versa, since I don't have an opinion on this. Just trying to understand the differences...

[davecheney]

I'm pretty sure when people compare an interface value against nil, they want to know if the interface contains a valid implentation or not. I think for the case of determining the type and value inside an interface value, reflect is already capable of handling this so we can make the langauge simpler by removing a common gotcha (happens weekly across the support forums I participate in) without adding a new special case identifier.

…

On Sun, 20 Aug 2017, 22:32 pcostanza ***@***.***> wrote: i == nil being true both when the interface is uninitialized as well as when it's initialized with a nil pointer would require implicitly compiling the code to two tests rather than one. My suggestion would more directly maintain a correspondence between how many tests are expressed in the source code and how many tests the source code is being compiled to. Also, your suggestion would require special handling in case you need to distinguish the two cases, through some additional constructs either as part of the language, or through some additional functions in the reflect package, for example. With my approach, you always have to distinguish the two cases, similar to what you already have to do now. I'm not saying my approach is better than yours, or vice versa, since I don't have an opinion on this. Just trying to understand the differences... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21538 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA71TxuEYJEuoyeTmEiTEFeUwPuvPks5saCdfgaJpZM4O8Vxm> .

[faiface]

@davecheney

I'm pretty sure when people compare an interface value against nil, they want to know if the interface contains a valid implentation or not.

The thing is, that a nil value (not a nil interface) can be a perfectly valid implementation. And we are not only talking about nil pointers, which are usually not valid implementations, but can be. We are also talking about nil slices, maps and channels, which are valid and used.

[davecheney]

The thing is, that a nil value (not a nil interface) can be a perfectly

valid implementation. Indeed. This is absolutely correct, but I argue _ifff_ nil was a valid implementation, the caller wouldn't be checking to see if the implementation was nil. But this proposal would not remove your ability to do type T struct {} func (t *T) Foo() { ... } type I interface { Foo() } var t *T var i T = t i.Foo()

…

On Mon, Aug 21, 2017 at 9:08 AM, Michal Štrba ***@***.***> wrote: @davecheney <https://github.com/davecheney> I'm pretty sure when people compare an interface value against nil, they want to know if the interface contains a valid implentation or not. The thing is, that a nil value (not a nil interface) can be a perfectly valid implementation. And we are not only talking about nil pointers, which are usually not valid implementations, but can be. We are also talking about nil slices, maps and channels, which are valid and used. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21538 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA7Nu8KwzK0m0w3jQUu1skKQJtWVEks5saLyJgaJpZM4O8Vxm> .

[faiface]

This is absolutely correct, but I argue ifff nil was a valid implementation, the caller wouldn't be checking to see if the implementation was nil.

I don't think so. A function/struct which accepts/stores an interface value has no idea nor control over the concrete implementations that get passed in. Therefore it can't assume that there is no valid nil pointer/slice/map/chan implementation.

[slrz]

Exactly. It's not a reasonable thing to test for. You shouldn't care.

Maybe I'm missing something. Can someone point to some place in the standard library where a check like this is put to good use?

[bcmills]

Another alternative would be to provide some sort of mechanism to declare types which have no zero-value.

var v nonnil[interface{}]  // ERROR: nonnil value initialized to nil.
...
if v != nil {  // ERROR: v is nonnil.
   ...
}
if v != (*someType)(nil) {  // OK
   ...
}

I believe that might also address some of the same concerns as #21737.

I feel like there is probably a concrete proposal somewhere for types without zero-values; anybody have a link handy? (I'm not having any luck finding it in the tracker.)

[jimmyfrasche]

@bcmills non-nil infects.

Say I have a struct like type S struct { f pkg.T } where T is a struct.

If I update pkg and after the update T contains a field with a non-nil type.

Everywhere in my package where I have var s S is now a compiler error and the same for anyone using my package who has var s mypkg.S in their code.

[bcmills]

If I update pkg and after the update T contains a field with a non-nil type.

Yes, that would be a backward-incompatible change: it changes the type from one that has a meaningful zero-value to one that does not, and the compiler would then enforce that the zero-value is not used.

But note that you can already do that today without compiler enforcement: for example, if you add a sync.Cond field to an existing struct type, the zero-value of the struct will have a Cond with a nil L field and panic when used.

(You could imagine a concrete proposal for types without zero-values that allows them to be declared but not used unless they are first assigned on all paths.)

[pcostanza]

Go is unusual in that it's possible to define methods that do something meaningful when invoked on nil values, rather than just panicking like in other languages (Java, C++, ...). The fact that people tend to write methods that panic on nil values in Go nevertheless is probably more an educational problem rather than a technical one. (Accessing fields through nil pointers is still problematic, though.)

My proposal is meant to solve the issue that people can get easily confused by nil having two very different meanings when used with interfaces. Untyped nil is effectively a very different value semantically than typed nil. This is something both programmers need to keep in mind as well as Go compilers. In other words, there is no benefit in representing typed and untyped nil with the same identifier, it's just confusing (literally). What I'm proposing is to just make that distinction explicit by using a different identifier or syntax. (I'm not married to the '{}' syntax, it could also be 'empty' or something else...)

I don't care much about changing anything else around nil. (Allowing a comparison against bare 'nil' to mean a comparison against any typed nil is not very important to me either, it just occurred to me to be a neat opportunity to add that as well. If this is dropped, I'm fine with it. I care a lot more about the syntactic distinction between typed and untyped nil.)