Proposal for Decimal64 and Decimal128 value-based classes
Raffaello Giulietti
raffaello.giulietti at gmail.com
Wed Mar 31 20:43:25 UTC 2021
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
More information about the core-libs-dev
mailing list