And, look what just showed up across the street:
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 <brian.go...@oracle.com
<mailto: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?
