RFR: JEP 360: Sealed Types (Preview)

[Brian Goetz]

> Actually I was talking about _adding_ a new permitted subtype (and 
> this is why I think it might be surprising and worth mentioning):

Yep, already covered that in my reply:

  " If its a matter of having added a permitted subtype, the change is 
also easy; if you don't want to handle the new case, add a default 
clause that throws (which is what you would have done in the first place 
if you didn't have the option to lean on exhaustiveness checking in the 
compiler.)"


>
> // Maintenance domain B built against A 1.0
> int z = switch (x) {
>     case A a: ...
>     case B b: ...
>     // no default
>     // boom
> }

Yes, this is exactly the case I was talking about.   I think we should 
be happy for the "boom"; it alerts us to the fact that we've tightly 
coupled to something we don't control.  And the remediation is easy; 
either handle it (which might be work), or throw when we see the novel 
value (either with a default, or probably better, with an explicit `case 
C`.)  And the throwing is what we would have been forced to write before 
without the sealing information.

> Given the fact that removal of a permitted subtype is also an 
> incompatible change (since either a public type is removed or it can 
> no longer be a subtype of the same sealed supertype) - it means the 
> set of permitted types has to be set in stone.

The "set in stone" part is where I think you've overstated your case.  
There's a flexible range of choices here, but there are both costs and 
benefits for each of them.

> Exhaustiveness check is a double-edged sword

I'd say it is the tight coupling across maintenance domains that is the 
double-edged sword.

The part of your point I agree with is: this is something users should 
be aware of, and make decisions with their eyes open.