Re: "Model 2" prototype status

[Timo Kinnunen]

Hi, 




Re: “I don't care about the syntax but the one you propose doesn't help IMO.”




I have to agree. You really get a sense that there is no overall design behind this syntax backing it up. 




For example, my current source of confusion is whether A<any T> is to be interpreted as A<ref T | any T | null> or as A<ref T | any T | !(null)>. (A note on the syntax being used: the presence  or absence of the nulltype amongst the bounds is to be interpreted literally.)




Seeing “Alternately, you can interpret "any T" as a union bound ("T extends Object | value")” suggests it’s the first interpretation that’s correct but then seeing “ Some operations that are allowed on ordinary tvars are not allowed on avars, such as assigning a T to an Object, assigning null to a T, etc.” suggests the correct interpretation should be the latter.


A properly designed syntax where such semantics can be expressed in a natural way will be helpful to have, one year from now. Would be much more helpful to have it right now though, IMHO…


















-- 
Have a nice day,
Timo.

Sent from Windows Mail





From: Rémi Forax
Sent: ‎Sunday‎, ‎August‎ ‎2‎, ‎2015 ‎21‎:‎52
To: Brian Goetz, valhalla-dev at openjdk.java.net







Le 1 août 2015 23:48:07 CEST, Brian Goetz <brian.goetz at oracle.com> a écrit :
>> I dislike the Foo<ref> / Foo<any> thing for several reasons.
>
>Not surprising.  This wasn't our first choice either.
>
>We spent a great deal of effort investigating whether it was possible
>to 
>re-use Foo<?> to mean Foo<ref> when the corresponding tvar is a ref 
>tvar, and to mean Foo<any> when the corresponding tvar is an any tvar. 
>Seems obvious, right?

It's not what i propose.
Foo<any> is Foo<any>.
Foo<ref> is Foo<?> because if Foo<?> is used in a 1.10 class file it's a reified type and if Foo<?> is used in a 1.9 class the compiler considers that is not reified and disallow to cast by example a Foo<any> to a Foo<?>. Practically, in that case, a user can use something similar to a checked collection that will check at runtime that each value have the right class.

>
>Several hundred hours later, the short answer is that things fall apart
>
>when a library is any-fied and the client is not recompiled; this would
>
>make any-fication a binary-incompatible change, which would be a loser.
>
> So with tears in our eyes, we reluctantly concluded that we needed to 
>differentiate between Foo<ref> and Foo<any>.  Once we swallowed that 
>pill, many things snapped into place.  So as sad as it is to have two 
>kinds of wildcard, I'm pretty sure its the right call.
>

I understand the need of differenciating between Foo<ref> and Foo<?> but i hope that instead of having to explain that to each Java dev, we can explain that only to the few that will stumble on the issue.

>You prefer another syntax?  Sure, I'm sure there are alternatives.  We 
>can talk about it -- but not this year!  We have way more important 
>things to work out before that comes anywhere near the top of the list.

I don't care about the syntax but the one you propose doesn't help IMO.

>
>As to bounds...  we're still working out the details of the interaction
>
>between value types and interfaces.  So its quite possible that Foo<any
>
>T extends Comparable> may in fact be meaningful.  (And if that's the 
>case, primitives might join the party too.)  Or not, we're not sure
>yet.

yes, forget the interfaces,
i suppose that it's not a big deal to not try to support them until you want to introduce value types in a later release :(

Rémi