* 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 :)

Reply via email to