Hyphenated Keywords and Unsigned Primitive Types

[John Rose]

If I were to add it before value types, I'd put in some
kind of decoration on method *signatures* to obviate
mangled names.  I partially developed a framework to
allow this in http://openjdk.java.net/jeps/8204937
It doesn't cover unsigned ints cleanly, but could be
adapted to do so.  The idea is that some annotated
version of "I" would signal the intention that the particular
32-bit value is to be interpreted in a special way.
The scheme is supposed to be open-ended with a
suitable metaobject protocol, so the an unsigned
int can be assigned its own API and interconversions
with regular int.  But all this works much better on
classes (not primitives) which already have infrastructure
for defining ad hoc APIs.  Like I said in the previous
message, it's better to steer towards a world where
primitives can be treated as having classes, and
then new primitives can be easily added, without
having to make new rules for the JVM.

— John

On Jan 14, 2019, at 7:13 PM, Tagir Valeev <amaembo at gmail.com> wrote:
> 
> Just for the information: Kotlin has experimental UInt type [1] which
> is library type implemented via
> another experimental feature called "inline classes" [2]. To resolve
> possible signature clash JVM
> method names accepting inline class parameters are mangled. No boxing
> is introduced:
> 
> $ cat Test.kt
> fun x(a: Int):Unit {}
> fun x(a: UInt):Unit {}
> $ javap -c TestKt
> Compiled from "Test.kt"
> public final class TestKt {
>  public static final void x(int);
>    Code:
>       0: return
> 
>  public static final void x-WZ4Q5Ns(int);
>    Code:
>       0: return
> }
> 
> As usual this creates a problem for constructors, but we all know some
> ugly ways to solve it.
> 
> Also I don't see the necessity to add more bytecodes. Standard library
> already has most of the
> necessary methods to perform unsigned operations (e.g.
> Integer.divideUnsigned), so compiler might
> delegate to these calls instead.
> 
> Kotlin support of unsigned types is still questionable, but it looks
> an interesting attempt to introduce them
> without changes in underlying VM.
> 
> [1] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-u-int/index.html
> [2] https://kotlinlang.org/docs/reference/inline-classes.html
> 
> On Mon, Jan 14, 2019 at 11:20 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>> 
>> Yes, many people would be thrilled to see the addition of unsigned
>> primitives.  (And the ML community would be thrilled to see half-floats,
>> and the vector folks would love to see 128/256/512-bit "superlongs").
>> 
>> Unfortunately, it is not the lack of a surface syntax that is the
>> primary impediment to adding new primitives; it's the JVM type system
>> itself.  The JVM provides the same eight primitive types as the Java
>> language, as well as reference types.  So, what would we translate them
>> to?  If we erase them to int, we have a problem; you couldn't overload
>> 
>>     m(int x) { }
>>     m(unsigned int x) { }
>> 
>> because they'd have the same VM type signature.  "Language fictions"
>> like this are sometimes a good move, but I suspect that this would only
>> make people happy in the short term, and lead to confusion and
>> complexity the day after that.  And if we translate them to references,
>> we have the performance problem that everything is boxed.
>> 
>> If you look at the bytecode set:
>> 
>>     https://en.wikipedia.org/wiki/Java_bytecode_instruction_listings
>> 
>> You'll see that many bytecodes are dedicated to primitive type
>> operations (iadd, iload, dmul, dload, etc).  And there's not room to add
>> the bytecodes we'd need for all the new primitive types.
>> 
>> This problem is one of the motivations for doing Valhalla -- to allow
>> new types to be written that have the runtime behavior of primitives,
>> but the user-definability of classes.  Valhalla is a very deep cut --
>> all the way down to the metal -- but by the time we're done, we'll be
>> able to write unsigned int (and others) as library classes (with a
>> sprinkling of intrinsification for arithmetic.)
>> 
>> 
>> On 1/13/2019 8:27 PM, Jacob Glickman wrote:
>>> Just throwing in my two cents on Brian's recent proposal regarding
>>> hyphenated keywords.
>>> 
>>> I think their addition to the language would be a great idea, and I'd like
>>> to use this opportunity to revive discussion regarding unsigned primitive
>>> types in Java, as I think hyphenated keywords would suit them perfectly:
>>> 
>>> `unsigned-int`, `unsigned-long`, etc.
>>> 
>>> I'm curious if anything else has changed since the last time unsigned
>>> primitive types were discussed that would warrant their addition to the
>>> language.
>>> 
>>> - Jacob Glickman
>>