yeah, real sum type ! at the same time, i'm already seeing the question what is the difference between an enum and an enum class trending on stackoverflow.
Rémi > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Alan Malloy" <amal...@google.com> > Cc: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts" > <amber-spec-experts@openjdk.java.net> > Envoyé: Lundi 18 Novembre 2019 00:39:01 > Objet: Re: Feedback on Sealed Types > And, look what just showed up across the street: > [ > https://github.com/dotnet/csharplang/blob/master/proposals/discriminated-unions.md > | > https://github.com/dotnet/csharplang/blob/master/proposals/discriminated-unions.md > ] > On 5/1/2019 11:34 AM, Alan Malloy wrote: >> Yes, that is what I suggest. Two points, though. >> First, the sugar benefit is at least a tiny bit larger than you say. You also >> get to omit instances of <T,U> if the interface is parameterized, as I expect >> it will often be. I argue you should get to omit public, too: the >> implementations of a sum should always be public, just as the accessors for a >> record should be, for the same reason: they are the entire propose of >> defining >> the type, and allowing variation here detracts from their semantic value. >> And second, I don't know that counting the number of saved characters/tokens >> is >> the best way to measure the benefits anyway. An enhanced for loop over an >> array >> is not that much shorter than an old-style for loop with an explicit index - >> in >> fact it probably saves fewer characters than a couple "implements FooSum". >> But >> it's clearly a win because it communicates intent better, and leaves fewer >> opportunities to make a mistake, either in writing the code or in reading it. >> Likewise the ability to say in a single token, "this is a closed sum" has >> legibility benefits aside from just being shorter. >> On Wed, May 1, 2019, 6:58 AM Brian Goetz < [ mailto:brian.go...@oracle.com | >> brian.go...@oracle.com ] > wrote: >>>>> I kind a like the intellectual separation between >>>>> - a sealed interface which represent a closed type and requires a permit >>>>> clause >>>>> and >>>>> - an enum interface which represent a sum type which is sugar on top of >>>>> sealed >>>>> interface + records. >>> To be clear, I think what Alan is suggesting, and what Remi is supporting, >>> is: >>> - Make “sealed” the primitive for defining closed types, as originally >>> proposed, >>> and also >>> - Make the following >>> enumerated interface Foo { >>> R(X), S(Y); >>> STUFF >>> } >>> sugar for >>> sealed interface Foo >>> permits R, S { >>> STUFF >>> record R(X) implements Foo { } >>> record S(Y) implements Foo { } >>> } >>> Is that correct?
