Proposal for Decimal64 and Decimal128 value-based classes
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed Mar 31 15:01:31 UTC 2021
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
More information about the core-libs-dev
mailing list