Typed variants of primitives
Jesper Steen Møller
jesper at selskabet.org
Wed Dec 2 14:54:06 UTC 2020
> On 2 Dec 2020, at 15.31, Brian Goetz <brian.goetz at oracle.com> wrote:
> The topic of "inline classes with no good default" is indeed a thorny one, and we don't yet have a good set of recommendations here. Possible moves include:
Rhetorically: So why is it really that we need default values for inline classes?
I understand it at the VM level: So that for instance ArrayList<T> eventually can allocate an array of inline T to some capacity, fill it with '.default', and manage the "liveness" of the default values at some higher level, without having to encode the initialized'ness of the array contents.
For raw arrays in Java, there is no "library", which leaves us with "new Year" giving us seven years of tribulation.
So at the VM-level, we need this to do what we want to do.
But at the language-level, couldn't we handle this differently somehow by marking inline classes which have undesirable defaults, and then issuing warnings in case anyone uses it (implicitly or explicitly)?
I do realize you'd still need one of:
> 2. Pick an arbitrary default (Jan 1, 1972.)
> 3. Invent a sentinel, try to make using it fail-fast (like a new kind of null), and make users check it (which they'll forget to do.)
to complete the semantics, but you'd still avoid solutions 1 and 4 and force more code to go through the restricted types "barrier to entry".
C++ and Rust have similar issues.
While they both support types without defaults at the language/type system level, they solve the collection-over-array challenge by trusting the library.
More information about the valhalla-dev