[External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Dan Heidinga" <heidinga at redhat.com>
> Cc: "Kevin Bourrillion" <kevinb at google.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, April 25, 2022 8:26:02 PM
> Subject: Re: [External] Foo / Foo.ref is a backward default; should be Foo.val /
> Foo

>>> What I’m thinking here about migration is that existing APIs can say “Optional”
>>> but field declarations can say Optional.val, getting additional footprint /
>>> flattening benefits, without perturbing the APIs (and with cheap conversions.)

>> Aren't most of the migration cases (at least for existing VBC)
>> targeting B2? They need to keep the reference semantics due to
>> existing code using null and will still get optimized inside a
>> compiled body.

> Sort of. For existing uses, we’re stuck with compatibility with the L protocol,
> certainly. But consider this example:

> class Foo {
> private Optional<Foo> f;

> public Optional<Foo> f() { return f; }
> }

> The API point has to stay LOptional, but the field could migrate further to
> QOptional, and there’s definitely value in that. With the current stake in the
> ground, we have no way to get there, but with Kevin’s proposal, we have the
> option to go further.

This seems very specific to Optional, for Optional storing null is always a mistake, but that's not true for other VBC, by example a deadline can be typed as an Instant with null meaning no deadline. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20220425/63ca75d8/attachment.htm>