Allow Null as the upper bound of a type variable?

[eernstg]

The language specification prevents an upper bound of a formal type parameter from being Null, because Null is a subtype of all other types, and the circularity prevention verbiage (catching cases like <X extends Y, Y extends X>) just says:

It is a static type warning if a type parameter is a supertype of its upper bound.

where static type warning means compile-time error in Dart 2. A similar situation will emerge with a denotable true bottom type Nothing, if such a type is introduced, say, in connection with the introduction of non-null types—the important part is simply that the bound cannot be a type which is a subtype of every other type.

We could consider this to be an accidental special case, in which case we would want to rephrase the specification.

We could also decide that it is useless to specify an upper bound which is the bottom type, because this implies that the bottom type is the only possible actual type argument, i.e., it implies that this type argument will never carry any useful information. Obviously, we'd then have requests for a lint to get rid of it ;-).

This issue is concerned with making a decision on which way to go on that.

[eernstg]

@lrhn, @leafpetersen, do you consider it worthwhile to change the specification in order to allow this?

[leafpetersen]

My general take is that non-uniformities are bad unless there's a good reason for them. I don't see it as being especially useful, but I see no real reason to disallow it. You can get it indirectly via instantiation, so... I'd say let it fly. If the developer really wants a type variable that can only be Null... who am I to say they're wrong?

[lrhn]

Why is <T extends Null>(){}<Null>() different from <T extends int>(){}<int>().
I'd say that Null is no more a supertype of itself than int is, so either we should err in both cases, or in none.

If we want to change the Null is a subtype of every type to ... except itself, then I'm all for it, but I think that's just commentary, and I don't think the implementations have any excuse for disallowing Null even with the current specification. The <: relation is reflexive, Null is not special in that regard. It looks like an implementation bug to me.

[eernstg]

We don't have a proof of int <: T given that T is declared to have the upper bound int (semantically, we only know that T is some subtype of int, so there's a good reason why we can't prove int <: T), but we do have a proof that Null <: T (until we introduce non-null types, which will make Null a non-bottom type again).

In any case, you both dislike the anomaly, so I'll make an adjustment to the spec.

[eernstg]

Created this CL to allow Null as a type variable bound.

[eernstg]

Closing: As of 4fd0404, the subtype circularity prevention rule in the language specification has be adjusted such that Null is now an acceptable upper bound for a type variable.