Q-types are dead, long live non-null side attributes

[Gernot Neppert]

Am 21.01.2023 um 14:50 schrieb forax at univ-mlv.fr:
>
>
> ------------------------------------------------------------------------
>
>     *From: *"Gernot Neppert" <mcnepp02 at googlemail.com>
>     *To: *"Valhalla Expert Group Observers"
>     <valhalla-spec-observers at openjdk.java.net>, "Remi Forax"
>     <forax at univ-mlv.fr>
>     *Sent: *Saturday, January 21, 2023 12:14:50 PM
>     *Subject: *Q-types are dead, long live non-null side attributes
>
>     Hi,
>
>     looks like a great idea to me - which is no wonder because I
>     propsed it back in June 2021 already, as this posting proves:
>
>     https://mail.openjdk.org/pipermail/valhalla-spec-observers/2021-June/001527.html
>
>     In that text, I wrote something very similar to Remi's reasoning:
>
>     "do we really need to have two different type-mirrors corresponding
>     to these descriptors?
>     Isn't the "Q-ness" rather a property of the Field, method Parameter or
>     method return-type, and therefore should be available there via
>     reflection as a simple boolean property?"
>
>
> Hi Gernot,
> there is a subtle difference, what you are describing is a model based 
> on a field/method property while the proposed model goes a step 
> further and also defines the nullability on types.
>
> This is important because we want to be able to flatten the array of 
> an ArrayList<@Nullable Complex>. Something we can not represent with 
> only a boolean property on fields/methods.
>
> regards,
> Rémi
>
Of course there are subtle differences, there always are :)

But the common ground of both proposals - and IMO a crucial difference 
to the approach that was taken in Valhalla so far - is this:

Move away from burdening the type-declaration of value/primitive classes 
with so many implications on its use-sites.

Also, do away with two different type-mirrors for primitive classes.

Rather, request specific behaviour at the use-sites (parameter 
declarations, return-types etc.)

BTW, I also proposed @Nullable (alternatively @ByRef) and its antagonist 
@ByValue. I also made a propsal on the overriding issue there:

https://mail.openjdk.org/pipermail/valhalla-spec-comments/2021-November/000024.html

Regards,

Gernot



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20230121/7d187761/attachment.htm>