* Could the doc make a clearer distinction (throughout) between which
facts about int/Integer are happening because we expect *all* bucket-3
classes to work that way, vs. which are special one-off tweaks for the
8 predefined types?
A "how are int/Integer special" section would indeed be useful. And I
think we haven't finished enumerating what goes in it; in the
discussions over inference, for example, several folks have been heard
mumbling "maybe we're trying to push the int/Integer analogy too far."
* I'm curious whether it would be /possible/ to make `int` no longer a
keyword, just a special kind of type alias that normal people don't
get to declare. I'm /not/ claiming that'd be worth actually doing;
just wanting to understand what forces would act to prevent it, as
part of understanding everything that makes the 8 builtin types
"irredeemably special".
In a previous world, `int` could have been an alias for `Integer.val`.
But we (happily) have banished .val from the world.
I think this is a useful exercise anyway, though; we have stumbled over
type-vs-class in a lot of places already with respect to B3, and int has
similar problems; most uses of `int` are types, but there's also
`int.class`, which means ... something. What exactly? And how does that
differ from Point.class / Point.ref.class /
Point.class.noNotThatClassTheOtherClass() ?
* I assume the reason "the JVM type Qjava/lang/Double cannot be
encoded with a Class object" is because the distinction between it and
D is intentional implementation detail.
Worse :( The J and D carriers use two slots, so even if we wanted to
abstract over the primitive carriers, this is kind of a dead end. The
java/lang/Double class allows us to encode List<double> with a class
that carries a double but fits in one slot.
* Since I think/hope it is /not/ true that `int` will be a subtype of
`Integer`, it's not 100% clear whether the phrase "array covariance"
in the doc is referring to the (desirable) property that `int[] <:
Integer[]`. I think it is.
int will not be a subtype of Integer, nor will Point be a subtype of
Point.ref. (It was this way in a previous iteration; the VM still
believes the latter, but we're probably going to disabuse it of same.)
Traditional array covariance is tied to subtyping:
T <: U
---------- T-Cov
T[] <: U[]
But, we're going to modify this rule somewhat. We define a relation
between types, called "extends".
A extends B = A <: B if A is a reference type
A.ref <: B otherwise
(We could write this more concisely as "A extends B == A.ref <: B",
since the .ref operator is idempotent.) We use "extends" for things
like bounds conformance; if we have Foo<T extends Comparable>, we treat
Foo<int> as being in bounds.
So our modified covariance is:
T extends U
-------------- T-Cov-Ext
T[] <: U[]
which gives us int[] <: Integer[], even though we don't have int <:
Integer.
This is no mere flourish; without it, erased generics don't work:
class Box<T> {
T value();
T[] asArray();
}
This erases to returning Object[], and if we want to specialize
Box<int>, asArray() should return int[], but to be compatible with
erasure, we need int[] <: Object[].
* I said in the meeting that "I don't think anyone cares" what kind of
exception gets thrown if trying to store null in an `Integer[]` which
is secretly an `int[]`. Well, I'm sure that's not at all true. :-) Sorry.
You're lucky they didn't show you their scars.
* Re: "a basic primitive class may declare an instance field of its
own primitive" -- does it really need that field, or can we nuke it
and just s/value/this/g throughout the file? If that could work, it
would be so much less confusing -- nothing circular! The only magic
would be "where are the actual bits??" but you don't see the bits of
an object header in `Object.java` either and the number of people this
bothers is a very round number.
Seems plausible :)
