Proposal for Decimal64 and Decimal128 value-based classes

[Maurizio Cimadamore]

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
>