Like I said, I sympathize with your position; you're saying "do we
really need this?", which is the right question to be asking. But, I do
believe you're wishing away a lot of stuff in the desire to get to the
answer you want, and that's where we disagree. I would be happy to find
another way to get there, if there is one, but "pretend the problem
doesn't exist" doesn't sit very well right now.
More inline.
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.
To get a NPEs when you store something in an array of T, you need the array to
be an array of inline type,
and currently it's not that easy because T is not reified.
Or, return a null from any method that returns a T. And this is the
problem; in order to safely write such generic code, this has to be a
property of the _method declaration_, not just something the
implementation doesn't happen to do right now. Which brings us to either:
- Use nullable types at the instantiation, or
- Force all generics to declare their nullability / non-nullability
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.
yes, you're right, but the downsize is that you have introduce V? in the type
system and everybody has no to think if he should choose V or V? for every
types.
Yes, that's the cost. And it's actually worse than you say, because on
Day One, you will only be able to say
new ArrayList<Point?>
and not
new ArrayList<Point>
and users will bitch and moan about "why can't the stupid compiler
figure out what I want", because they are unaware of the _future_
ambiguities they would be subject to if they did that.
The alternative is to merge L10/L100, and no one gets values for a long
time more, which also sucks.
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 don't need V? if generics are fully reified so introducing V? 20 years from
now will look stupid.
There's a kernel of a point here, but you've overstated it by a hundred
million billion percent :)
V? remains useful, but given the choice between parameterizing over V or
V?, _most of the time_ users will probably choose V. That doesn't mean
V? is stupid; it's just not the most common case. Which is _exactly why_
we gave "V" the good syntax and "V?" the less good syntax, so that when
we get to that world, we won't have chosen the wrong default (again.)
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.
but nothing break in this mode.
Nothing breaks, but values can't be used with most generics for the next
ten years. That leads to "value types are useless", wich we don't want.
- Let users instantiate erased generics with values, and let them blow up when
the inevitable null comes along. That’s what you’re proposing.
until people annotate the method/class that doesn't support value type.
Sorry, but I can't take this option seriously. Imagine all the generic
code in all the world. Now imagine all the classes that might, in some
case, cause a null to show up in a T. (This includes every generic
interface, as there is always a potential subtype that returns null from
a T-bearing method.) Call this latter category B (for Bad). Now: what
percentage of B do you think will be prperly annotated after a month? A
year? Ten years? 99.9999%? No. 99%? No. Probably closer to 10%.
Which reverts to: "try it and see if it blows up." This is not the safe
programming experience we want people to have.
- 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.
which doesn't scale because your asking all your users to think as API
developers, not something i want to do when i just want to use an API.
So far, this is the only acceptable approach we've found. If you can
find a better one, we're all ears!
I believe that the issue is that V? should work as a box and currenty
V? is to powerful/useful as a box so people will start to use it as a
true type.
This is a valid discussion (start a new thread). Basically: we've
gotten rid of boxes because they are semantically sketchy (accidental
identity) and harder to optimize, but you're saying: people understand
boxes, they don't understand this T or null thing? Fair point: let's
discuss this (on a new thread.)
- V? should not be called V?, it's to short, you should have some ceremony that
show you that V is the real deal, V.box was better
If it really were a box, then V.box was better. But it is not like the
boxes that people understand, so V.box is an utterly terrible name for
the semantics we have (and people's understanding of boxes.) But, we
are open to another way to write it, if you dislike V? so much.
