[External] : Re: 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: "John Rose" <john.r.rose at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Lundi 25 Janvier 2021 13:50:48
> Objet: Re: [External] : Re: Relaxed assignment conversions for sealed types

>>> the generated bytecode would be the same, but we would also get a compile-time
>>> assertion that B is indeed total on A, and an error message when it is not.
>>> (There was a long thread about this, but basically: I started programming with
>>> sealed classes, and found it almost irrersistible to use such blind casts,
>>> because “of course” they would succeed, but this makes for brittle code.
>>> There’s a separate discussion on whether we should just allow A to be assigned
>>> to B, but this is kind of orthogonal.)

>> I prefer a declaration site keyword instead of a use site declaration, use site
>> declarations are not very Java-ish.
>> So something along the line
>> sealed interface A permits only B {}

> But the problem is not at the declaration site. The declaration is fine; the
> problem is that the use site makes use of an assumption-at-a-distance, one that
> could be invalidated by someone else's action, and users might want to engage
> the compiler to help them detect when that happens. The declaration site hint
> doesn't add anything to the status quo, as it can't prevent the "only" from
> being dropped in the future.
Adding a new subclass in the permitted subclass list is actually a compatible change. 

Adding the keyword "only" allows to say that adding a new subclasses is not a compatible change. 
Dropping only is also an incompatible change. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210125/925eb928/attachment-0001.htm>