<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Gernot Neppert" <mcnepp02@googlemail.com><br><b>To: </b>"Valhalla Expert Group Observers" <valhalla-spec-observers@openjdk.java.net>, "Remi Forax" <forax@univ-mlv.fr><br><b>Sent: </b>Saturday, January 21, 2023 12:14:50 PM<br><b>Subject: </b>Q-types are dead, long live non-null side attributes<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><p>Hi,</p>
<p>looks like a great idea to me - which is no wonder because I
propsed it back in June 2021 already, as this posting proves:<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/valhalla-spec-observers/2021-June/001527.html" target="_blank">https://mail.openjdk.org/pipermail/valhalla-spec-observers/2021-June/001527.html</a><br data-mce-bogus="1"></p>
<p>In that text, I wrote something very similar to Remi's reasoning:
<br>
</p>
<pre>"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?"</pre></blockquote><div><br></div><div>Hi Gernot,<br data-mce-bogus="1"></div><div>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.</div><div><br data-mce-bogus="1"></div><div>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.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>regards,<br data-mce-bogus="1"></div><div>Rémi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>