> The first case is a corner case and for generics, it works until someone try
> to stuff null into a value type.
>
> So instead introducing nullable value types in the language which make the
> language far more complex than it should be, i think we should come up with a
> far simpler proposal, to have a declaration site tagging of the method that
> doesn't work with value types.
>
>
> // proposed syntax
> interface Map<K, V> {
> "this method doesn't work if V is a value type" public V get(Object o);
> }
We explored this idea in M3; we jokingly called this “#ifref”, which is to say,
we would restrict members to the reference specialization. This was our first
attempt at dealing with this problem. We gave up on this for a number of
reasons, not least of which was that it really started to fall apart when you
had more than one type variable. But it was a hack, and only filtered out the
otherwise-unavoidable NPEs.
More generally, there’s lots of generic code out here that assumes that null is
a member of the value set of any type variable T, that you can stuff nulls in
arrays of T, etc. Allowing users to instantiate arbitrary generics with values
and hope for no NPEs (or expect authors of all those libraries to audit and
annotate their libraries) is not going to leave developers with a feeling of
safety and stability.
Further, allowing users to instantiate an ArrayList<Point> — even when the
author of ArrayList proposes up and down (including on behalf of all their
subtypes!) that it won’t stuff a null into T — will cause code to silently
change its behavior (and maybe its descriptor) when ArrayList is later
specialized. This puts pressure on our migration story; we want the migration
of ArrayList to be compatible, and that means that things don’t subtly break
when you recompile them. Using ArrayList<V?> today means that even when
ArrayList is specialized, this source utterance won’t change its semantics.
Essentially, erased generics type variables have an implicit bound of “T
extends Nullable”; the migration from erased to specialized is what allows the
declaration to drop the implicit bound, and have the compiler type-check the
validity of it.
We have four choices here:
- Don’t allow erased generics to be instantiated with values at all. This
sucks so badly we won’t even discuss it.
- Require generics to certify their value-readiness, which means that their
type parameters are non nullable. This risks degenerating into the first, and
will be a significant impediment to the use and adoption of values.
- Let users instantiate erased generics with values, and let them blow up when
the inevitable null comes along. That’s what you’re proposing.
- Bring nullity into the type system, so that we can accurately enforce the
implicit constraint of today’s erased generics. That’s what I’m proposing.
I sympathize with your concern that this is adding a lot of complexity.
Ultimately, though, I don’t think just letting people blindly instantiate
generics that can’t be proven to conform to their bounds is not helping users
either. Better suggestions welcome!
(A related concern is that V? looks too much like ? extends V, especially in
the face of multiple tvars: Map<V?, ? extends U>. This may have a syntactic
solution.).
