Hyphenated Keywords and Unsigned Primitive Types

[Tagir Valeev]

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
>