Proposal for Decimal64 and Decimal128 value-based classes

[Raffaello Giulietti]

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).


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