Static check for null.foo or (throw 0).foo is unspecified

[rmacnak-google]

The spec says that the static type of null or a throw expression is bottom. But it does not say what members bottom has.

@lrhn

[lrhn]

True, that is a problem.

The ⊥ type is really a hack to allow null to be assignable to everything, at which point the ⊥ goes away and you have the other type. Calling something directly on the null value is probably not intended - or maybe just not expected - although I can see that there might be a reason to fetch the hashCode of null for some operations. Calling something on a throw expression is just silly, but I guess it's not even wrong. You would expect throw to have type void, but that makes it hard to use as, say, a branch of a conditional expression, so using ⊥ is more useful, as long as you do combine it with something else that can absorb the ⊥ type.

Personally I'd be fine with not allowing any calls directly on null, but for backwards compatibility we probably should say that it allows the same members as the Object type. After all, every object does, and whatever ⊥ contains, it's definitely objects.

It's interesting that null == foo is also undefined even if the == syntax doesn't actually call the == operator of null.

@eernstg WDYT?

[eernstg]

The usual interpretation of a bottom type is that it is a subtype of all other types, in which case it will have "all members, with all signatures". This hasn't been spelled out in the spec, but it explains why null is an acceptable value for all assignments according to the type checker (even without relying on an implicit downcast).

I guess the real issue here is that an expression of type Null allows for access to all those members, which is misleading because of the runtime error. However, that could be treated as a special case, and a hint could be emitted for invocations of any method outside the ones that Null actually implements.

[munificent]

Duplicate of #27273.