The fate of int, int.ref, and Integer

[Kevin Bourrillion]

On Thu, Jun 4, 2020 at 7:16 PM John Rose <john.r.rose at oracle.com> wrote:

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”.
>

I don't know what this means -- I see separate usages of "inline class" and
"inline type" and they make sense to me.


> 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 should probably open every email with a reminder that my concerns always
live purely within the language model.)

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.
>

That kind of fu is the sort I'm skeptical of; the only thing you really
need this class for is to augment the existing predefined type with methods
so that it's reference projection can be the better version of Integer (and
if static int-accepting methods on Integer become callable as
myInt.method(), that's nice gravy too). That file doesn't need to "explain"
anything about how ints already work, imho. It's okay that primitives are
special.

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).
>

Satisfied? No, it wasn't meant to be an explanation of very *much*, just
why int became a class.

Off the cuff, it's clean to make 42.toString() and myInt.toString() work if
possible, to emphasize that there's nothing about ref-ness that somehow
enables method calls (and further demolish the popular misconception that
"dot means dereference").


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”.
>

I don't feel like it should require much handwaving, just avoiding an
unnecessarily specific definition for "inline type". That means there will
be a little more to say about *user-defined* inline types beyond the
general case, but that's okay. I have no idea if what I'm saying is
controversial; I'm just saying that `int` has the *essential* qualities of
any inline type already.

(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.
>

My view was that it's the *next* part below that becomes twisty and that we
would need to do carefully.

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.
>

Not sure if by "instead of" you mean those types actually being
convertible; I'm expressing that I could accept a world where those types
are just different, but people have incentive and some means to make
discrete migrations over. But don't get me started about type migrations.
:-)



>  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.
>

Absolutely, impossible to get rid of Integer. But there can eventually be
codebases that ban it, and use only int.ref, like Google's one day would.
My basic orientation is that the more `Integer` is left alone, the less
confusing everything is. Everyone is very accustomed to Living With Certain
Things That Suck, and it's better when we can store our knowledge in neat
boxes that don't all bleed together, Anyway, the details could override
that orientation as we get into them.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com