[External] : Re: Relaxed assignment conversions for sealed types

[Brian Goetz]

>     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.

> I recently as an exercise tried to write a part of ZIO in Java, just 
> for fun and because it uses patterns extensively. This type of cast 
> appears so often that I think i'm tilting toward just allowing A to be 
> assigned to B.

I agree (see earlier argument about "it's like a union type"), but I'm 
not sure that means that we are never interested in marking a cast total 
also.
>
>
>
>          case Foo(Bar(total Baz b)):
>
>     we might insert an extra case right after for:
>
>          caes Foo(Bar(var remainder)): throw
>
>     to close off the side paths.
>
>
> By inserting a new case, you don't mean literally inserting a new case ?

Sorry, I meant an extra dynamic *cast*.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20210125/c20f1ee5/attachment.htm>