proposal: Go 2: Add `typednil` keyword for checking whether an interface value is a typed nil.

[jaekwon]

Following from this proposal: #21538, I think an alternative proposal would be to "simply" introduce a new keyword called typednil. It can only used for comparison, and it would have behavior identical to the following code:

func IsTypedNil(o interface{}) bool {
	rv := reflect.ValueOf(o)
	switch rv.Kind() {
	case reflect.Chan, reflect.Func, reflect.Map, reflect.Ptr, reflect.Slice:
		return rv.IsNil()
	default:
		return false
	}
}

This way, the current nil keyword behavior is preserved -- a zero value for interfaces as well as channels, funcs, maps, pointers, and slices, but we could now do the following:

var a interface{} = (*foo)(nil)
a == nil // false
a == typednil // true
var b *foo = nil
var b *foo = typednil // compile time error
b == typednil // compile time error

[pcostanza]

I agree with @jaekwon that a simpler proposal than #22729 should be preferred. In #22729, a lot of additional identifiers are added, but most cases of ambiguities between different uses of ‘nil’ are already caught by the static type checker, so I don’t think it’s necessary to add these additional identifiers. The case of an empty-interface nil vs. a typed nil is the only case that is ambiguous, as far as I can tell, and is not caught by the type checker, and can therefore lead to confusing results that are potentially only caught later in testing or even after deployment. So I think a proposal that solves this particular case only is simpler and preferable.

However, I don’t agree with @jaekwon that a typednil is a good solution, because it doesn’t prevent the potentially erroneous ‘v == nil’ test when v is of an interface type, so doesn’t help in solving the issue that bugs may be lurking in code until testing or later. For this reason, I still prefer my suggestion in #21538. I’m not picky about the syntax, though, it can be my suggestion {}, or null, or nilinterface, or something else. What is more important to me is the semantics.

[slrz]

The fundamental objections raised in #21538 and elsewhere remain unaddressed. If you shouldn't care about the specifics a caller chooses to implement an interface in the first place, why make it any easier to do?

In my opinion, the desire to put this weird constraint on interface values doesn't indicate a flaw in the language that needs to be fixed but rather points to a potential issue with your use of interfaces. These details are up to the implementor of the interface to decide, not on its users. If you want to provide special behaviour for a particular implementation, use a type assertion. Otherwise, you just assume that the passed value is a correct implementation of the interface contract. Using weird heuristics like "is not a nil value" or "is an integer value equal to 42" on the contained value won't do any good here.

[bcmills]

This proposal is missing background information. What concrete problems is it intended to address?

(Some illustrations or experience reports would be helpful.)

[bcmills]

This clearly relates to @davecheney's experience report, but I think there is something missing from the story: where does the proposed typed-nil-check occur, and why? (That is, what are some concrete call sites where you would actually use this check?)

In particular: if the nil instance of the concrete type is not a valid implementation of the interface, how do you end up with the nil as an instance of that interface in the first place? How do you know that whoever put the nil pointer in that interface value didn't mean for it to be a meaningful implementation?

[jaekwon]

@slrz @bcmills

This came about while implementing Amino, an encoding system inspired by Protobuf3. I could find the exact place where it caused an issue, but it seems to apply to encoding libraries in general.

For example, using encoding/json as the example, https://golang.org/pkg/encoding/json/#Encoder.Encode

func (enc *Encoder) Encode(v interface{}) error

Here, we do care about "the specifics a caller chooses to implement an interface in the first place", because that's what codecs should care about. Or put another way, Golang objects are for more than conceptual-interface-implementations, or its "function". Sometimes what's more important is the form of the object, regardless of its function or how it's referred to. Amino takes this to its logical conclusion, and handles interfaces/concrete-types natively, and makes for a really nice codec.

To focus only on Golang's awesome interface system is to ignore a crucial aspect of the language, imo. Go2 should marry both form and function well.

[jaekwon]

@pcostanza I like your reasoning as well. I wonder how difficult the migration will be. If migration is easy, I agree with your proposal 100%.

[bcmills]

Here, we do care about "the specifics a caller chooses to implement an interface in the first place", because that's what codecs should care about.

For the specific case of json.Encoder and similar APIs, a nil pointer that implements json.Marshaler can encode itself to an empty JSON struct (or the keyword null). And if we receive a nil pointer that does not implement json.Marshaler, we're going to use reflect anyway, so the typenil comparison in the language seems to provide no additional benefit.

For those use-cases, it seems like the only benefit of moving the check out of reflect and into the language proper is so that you can convert the codec into a generic API (#15292). But in that case, you would presumably be working with concrete pointer types anyway, so the interface comparison is still moot.

For other kinds of codecs, particularly involving generated code, it often makes sense to define a reflection API for the generated code rather than relying on Go's `reflect' package (see golang/protobuf#291 and golang/protobuf#364).

So I still don't really understand the concrete use-case. Some examples of how it would be used in existing code would be helpful.