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.
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" <brian.go...@oracle.com>
*À: *"Tagir Valeev" <amae...@gmail.com>
*Cc: *"amber-spec-experts" <amber-spec-experts@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.
