The fate of int, int.ref, and Integer

[John Rose]

On Jun 4, 2020, at 7:00 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> Hello friends,
> 
> A couple thoughts on the fate of the primitives and wrappers.
> 
> First, on nomenclature, I think the most useful definitions of what it means to be an "inline type" are those that reveal the primitives to already be inline types. Java's always had them, but it hasn't had user-defined inline types, because it hasn't had inline classes (and classes are how we user-define types). That's clean, and it's not even a retcon.

+1  We have tried to keep “works like an int” as a goal.  I don’t think we’ve
compromised too much away from that; I think your formula works, except
for the technical fact that “inline” is always followed by “class”.

> Also on nomenclature, I want to avoid phrases like "you can expand the set of primitives"; no, I still think that "primitives" should always apply to the eight predefined, irreducible inline types. User-defined inline types are always composite (how could they not be?).

Yes.  But:  I expect that JVMs will sometimes secretly define things that look
like inline classes but in fact are physically atomic (except bitwise of course).
Vectors in AVX are like this:  They go in one register, not many.  I expect
such things to be hidden from the end user, in places like jdk.internal.types,
and wrapped in ordinary inline wrapper classes for public consumption.

> 
> I approve of the idea of writing int.java etc. files in order to add methods to `int`, and add interfaces to `int.ref`. It is fine if these files are essentially "fake" (they don't actually bring the primitives into existence as other classes do). I think attempts to try to make them look "real" would mean letting them do things other inline types can't and it definitely wouldn't seem worth it to me.

Yep.  We are a long way from doing so, I think.  We might like some kind of
Haskell-flavored fu that lets us relate those things to their operators.  At
least, I’d like to know something about that road ahead, before committing
to the initial contents of int.java.

> What I would explain is "In Java <X, `int` was not a class; it didn't need to be because it had no members. Now in Java >=X that it has members and implements `Comparable`, it is a class for that reason, but the type itself is still predefined with or without that class.”

I think people would not be satisfied with such an explanation, until we can
explain why 42.toString() does or doesn’t work, and how 42 < 43 connects
to a call to Comparable.compareTo, and (worst of all) how 1.0 == 1.0 connects
to the Java == operator on classes and/or Comparable.compareTo (pick one).

So we’re pretty far from making int into a class, or from writing int.java.
But, yes, we can say that primitives are (in some sense to be defined or hand
waved away) “inline types”.

> 
> (wart: yeah, arrays have no class, yet sure seem to have members `length` and `clone` anyway. oh well.)
> 
> I also approve of giving the new `int` class everything it needs so that the `Integer` class becomes obsolete; that is, there would no longer be any good reason to use it except when forced by legacy code. (Of course, anything that wants to depend on identity or locking of such an object I will just declare to be legacy code, so it works!) Really though, don't bring `getInteger` over when you do.

This is a maze of twisty passages.  I agree there’s are ways through it.
We want to choose a way through that doesn’t leave us disgusted with
ourselves in the morning.

> However, I am highly skeptical of attempts to do anything else beyond that. I've seen, at least, the allusions to some kind of aliasing between `int.ref` and `Integer`. That seems unnecessary to me, and more to the point, I feel that it can only make things more confusing to users; that in fact it will cause a large share of all the confusion they do feel. So wait, what IS the wrapper class then? What IS this reference projection then? I see no benefit to blurring that line, at this point.

Interesting.  I don’t have a strong feeling, but I *do* hope that we could define
by fiat that Integer is the ref-projection of int, sooner rather than later.
You are prompting me to re-examine this idea, and see what it might buy us.
At the very least, I’d like to be say List<int.ref> instead of List<Integer>
and get away with it.  This is touching on exactly what we can do (short
and long term) with generics, which is an open question.

Are you saying that it would be risky to declare that int.ref == Integer, because
it would make it harder to get rid of Integer?  Isn’t it going to be impossible
anyway to get rid of Integer?  I think the problem is mainly to make Integer
as palatable as possible in the future, perhaps deprecating some of the oldest
cruft, and (at least conceptually) attributing the useful parts to int, even before
we venture to write int.java.

My $0.02.  Thanks for raising the question.

— John