Proposal Details
An interface value with the type assigned to it (the itable) but without the actual data to use it upon, is not considered as nil.
This problem caused me as many unexpected and quite hard to trace problems as the infamous the variables declared by a “for” loop were created once and updated by each iteration.
We fixed this one, why shouldn't we move forward.
v := any((*int)(nil))
if v != nil {
panic()
}
Comment From: gabyhelp
Similar Issues
- proposal: Go 2: use an identifier other than nil for uninitialized interfaces #24682
- Proof that golang's interface type (nil) current judgement is wrong #67879
- proposal: Go 2: equality between an interface and nil should by default compare only by value (and not also type) #60786
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
Comment From: adonovan
This is certainly one of the more confusing things that newcomers to Go have to learn (and it occasionally catches old hands too), but even if we wanted to, there's simply no way we could make this incompatible change to the core semantics of interfaces. A very large number of programs rely on the fact that a nil *int pointer in an any value is non-nil.
Closing as infeasible.