Relaxed assignment conversions for sealed types

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Dimanche 22 Novembre 2020 19:32:38
> Objet: Re: Relaxed assignment conversions for sealed types

> I guess I deserved that, because I wasn't being specific, but I was looking for
> slightly different feedback :)

> What I was trying to ask for feedback on was, that we have two problems in
> search of solutions, and I was proposing that they are both, at some level, the
> same problem -- and might benefit from a common approach.

A cast is equivalent to an if that throws a CCE in the else branch and a total-switch with one case (because there is only one subtype) throws an exception in its default branch. 
So they are roughly equivalent without squinting too much (the behavior for null is also different). 

One problem we have is how to declare a total switch when it's not a switch expression, so the problem is a little different than just how to declare a total switch. 
This problem can be seen as even more specific if we say that once there is a "case Type", then the switch is total, because it becomes how to declare a total switch when it's a switch statement on an enum (and maybe an enum on true/false). 
At that point, it can be seen as a corner of a corner case because of backward compatibility that we will not fix or choose to fix it using the cast to void syntax proposed earlier (the least bad proposed syntax IMO). 

About using total as a prefix for a cast, I suppose that the idea is to have a compile-time error message if the sealed type permits more than one class. 
While it's cool, i'm not sure we need that and an annotation at declaration site similar too @FunctionalInterface seems a better idea than using 'total' at each use site. 

regards, 
Rémi 

> On 11/19/2020 4:13 PM, Remi Forax wrote:

>> We have avoided in the past to mix the class restriction and the type system.
>> By example, even if a class A is declared final, List<? extends A> is not
>> equivalent to List<A>.

>> For me, you want to steer the type system to work more like a close world type
>> system,
>> so it's not very consistent with the existing semantics and the fact that we
>> have chosen to add the keyword 'sealed' instead of introducing a special
>> construct to define a sum type.

>> regards,
>> Rémi

>>> De: "Brian Goetz" [ mailto:brian.goetz at oracle.com | <brian.goetz at oracle.com> ]
>>> À: "Tagir Valeev" [ mailto:amaembo at gmail.com | <amaembo at gmail.com> ]
>>> Cc: "amber-spec-experts" [ mailto:amber-spec-experts at openjdk.java.net |
>>> <amber-spec-experts at openjdk.java.net> ]
>>> Envoyé: Jeudi 19 Novembre 2020 21:47:59
>>> Objet: Re: Relaxed assignment conversions for sealed types

>>> Bump -- hoping for feedback on this thought:

>>>> BarImpl bi = (__static BarImpl) b;

>>>> Pulling on this string some more — I think there’s a connection between this
>>>> feature and total statement switches. We’ve been looking for a way to make
>>>> statement switches total, and here, what we’re looking for is a way to make
>>>> _casts_ total. Which suggests this is one feature, not two. So perhaps:

>>>> switch-total (x) { … } // a switch, but with added bonus totality checking

>>>> BarImpl b = (total BarImpl) bar // a cast, but with added bonus totality
>>>> checking

>>>> Obviously we can use another word besides `total`, but it’s a pretty good straw
>>>> man.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20201122/19c21582/attachment.htm>