On 31/03/2021 21:43, Raffaello Giulietti wrote:
Ciao Maurizio,
admittedly, yours is a fairly convincing argument to wait for the
completion of Valhalla, or at least JEP 401.
Personally, I wouldn't mind having to denote the primitive class as
Decimal128.val in some future (2022? 2023? who knows?) if I could use
Decimal128 tomorrow, but I understand your concerns in defending the
interests of the community at large (which includes myself).
Well, I think the problem with a lot of these things is consistency.
Decimal128.val is not horrible, although it is the wrong default (think
of Decimal128[] which you would probably want flattened?).
The worse aspect is if _some_ of these types are added before, and some
after, so you have to remember to use Decimal128.val, but HalfFloat is
ok (as it has been added after Valhalla).
Considering that these things can happen, I'd be reluctant to go ahead
and add these types now.
What I'd be curious though, is if the @ValueBased annotation could be
enhanced to say _which_ primitive class default you want (and then javac
could enforce extra checks if you pick the "val" default). If something
like this was feasible (cc'ing Dan), maybe some of the friction here
could be removed?
Maurizio
Greetings
Raffaello
On 31/03/2021 15:23, Douglas Surber wrote:
Rather than waiting on Valhala I would prefer that this project be
fast tracked and added to OpenJDK ASAP.
There is a catch here.
While in principle, we can add these as value-based classes, and
migrate to Valhalla later, there is a biggie difference between doing
it before/after.
When it comes to "migrated" primitive classes, there is a choice in
how to interpret the "old" utterances of the class name. Let's say
that class Foo is migrated to be a primitive class; does that mean
that all uses of Foo in existing program will automatically get
flattening? Or will references to Foo be interpreted in a
conservative fashion, so as to allow the same operations as before?
One important difference in semantics is assignment to `null` which
is prohibited under flattened semantics, but allowed under "indirect"
(or by reference, if you will) semantics.
In other words, under the current plan, if Decimal128 is added now
and migrated later, utterances of Decimal128 will behave like they
used to pre-Valhalla, and, to take advantage of flattening you would
need to opt-in with some keyword (e.g. Decimal128.val).
To me this is kind of a strong argument against going with these
classes now (as much as I understand how useful they'd be even w/o
Valhalla) - and preserving the "good" name (Decimal128) for the
flattened case seems worth, IMHO, waiting few more cycles.
Maurizio
