Feedback on Sealed Types

[forax at univ-mlv.fr]

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.goetz at oracle.com>
> À: "Alan Malloy" <amalloy at google.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts at 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.goetz at oracle.com |
>> brian.goetz at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20191118/77cb1b03/attachment.html>