Feedback on Sealed Types

forax at forax at
Mon Nov 18 08:55:58 UTC 2019

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. 


> De: "Brian Goetz" <brian.goetz at>
> À: "Alan Malloy" <amalloy at>
> Cc: "Remi Forax" <forax at>, "amber-spec-experts"
> <amber-spec-experts at>
> Envoyé: Lundi 18 Novembre 2019 00:39:01
> Objet: Re: Feedback on Sealed Types

> And, look what just showed up across the street:

> [
> |
> ]

> 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 |
>> brian.goetz at ] > 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);

>>> }

>>> sugar for

>>> sealed interface Foo
>>> permits R, S {


>>> record R(X) implements Foo { }
>>> record S(Y) implements Foo { }
>>> }

>>> Is that correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list