<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>That Ceylon example is exactly what I've been thinking of, too.</div><div><br></div><div>I understand that Swift's enums work differently, though. But I do like Ceylon's union types (them being able to represent enums being just a minor part).</div><div><br></div><div>-Thorsten </div><div><br>Am 27.01.2016 um 03:09 schrieb Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>I think I understand where you're coming from now in that you can think of:<br></div><div><br></div><div><font face="monospace, monospace">enum Foo {<br></font></div><div><div><font face="monospace, monospace"> case Bar(x: Int, y: Int)</font></div><div><font face="monospace, monospace"> case Baz(a: Double, b: Double)</font></div></div><div><font face="monospace, monospace">}</font></div><div><br></div><div>as:</div><div><br></div><div><font face="monospace, monospace">struct Foo {</font></div><div><font face="monospace, monospace"> let Bar: (x: Int, y: Int)</font></div><div><font face="monospace, monospace"> let Baz: (a: Double, b: Double)</font></div><div><font face="monospace, monospace">}</font></div><div><br></div><div>with special handling for storage and pattern matching.</div><div><br></div><div>I was thinking of it more in terms of mapping to:<br><br><div><font face="monospace, monospace">struct Foo {</font></div><div><font face="monospace, monospace"> typealias Bar = </font><span style="font-family:monospace,monospace">(x: Int, y: Int)</span></div><div><font face="monospace, monospace"> typealias </font><span style="font-family:monospace,monospace">Baz = (a: Double, b: Double)</span></div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace"> let storage: MagicStorageOfMaxSize</span></div><div><font face="monospace, monospace">}</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">with special handling for type use and pattern matching.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The former is probably closer to the implementation and is easier to explain. If that's the case, I'm +1 on changing the case naming convention. The initial capital letter probably put "type" in my head in the first place along with ways of using enums from other languages like Ceylon:<br><br></font><pre class="" style="word-wrap:break-word;color:rgb(231,233,219);font-family:'andale mono','lucida console',monospace;margin-top:0px;margin-bottom:0px;padding:10px;border:0px;font-size:14.5px;vertical-align:baseline;font-stretch:normal;line-height:1.5;background-color:rgb(47,30,46)"><code class="" style="font-family:Inconsolata,Monaco,Courier,monospace;margin:0px;padding:0px;border:0px;vertical-align:baseline;font-stretch:normal;line-height:1.5"><span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(6,182,239)">abstract</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">class</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Node</span>() <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">of</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Leaf</span> | <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Branch</span> {}
<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">class</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Leaf</span>(<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(6,182,239)">shared</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Object</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(239,97,85)">element</span>)
<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">extends</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Node</span>() {}
<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">class</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Branch</span>(<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(6,182,239)">shared</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Node</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(239,97,85)">left</span>, <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(6,182,239)">shared</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Node</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(239,97,85)">right</span>)
<span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(184,186,175)">extends</span> <span class="" style="margin:0px;padding:0px;border:0px;font-weight:inherit;font-style:inherit;font-family:inherit;vertical-align:baseline;color:rgb(254,196,24)">Node</span>() {}</code></pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 7:49 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Tue Jan 26 2016, Trent Nadeau <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> I should clarify. I mean that they're like types in that they have a<br>
> unique scoped name with fields.<br>
<br>
</span>struct X {<br>
static var y: Int = 3<br>
}<br>
<br>
X.y has a unique scoped name. What's all this about fields? I don't<br>
understand that part.<br>
<span class=""><br>
> A union with cases with associated values is a sum types of product<br>
> types. Obviously, they can't be used like "real" types as formal<br>
> parameters, etc.<br>
><br>
> I don't see them as values or initializers but very constrained types. For<br>
> instance, in C you could have something like:<br>
><br>
> struct Foo {<br>
><br>
> int tag;<br>
><br>
> union {<br>
><br>
> struct Bar {<br>
><br>
> int x;<br>
><br>
> int y;<br>
><br>
> } bar;<br>
><br>
> struct Baz {<br>
><br>
> double a;<br>
><br>
> double b;<br>
><br>
> } baz;<br>
><br>
> } data;<br>
><br>
> };<br>
><br>
> which would be equivalent to Swift's:<br>
><br>
> enum Foo {<br>
> case Bar(x: Int, y: Int)<br>
> case Baz(a: Double, b: Double)<br>
> }<br>
><br>
> Bar and Baz in the C code above are actual types just unusable outside of<br>
> the sum type (tagged union).<br>
<br>
</span>The fact that an anonymous union in C hides the types declared within is<br>
just a quirk of that language. You didn't even need to name Bar and Baz<br>
in the `C' code. The Bar and Baz in your swift code are more similar to<br>
bar and baz (lowercase) as they are required in order to access members<br>
of the sum.<br>
<br>
FWIW, there's a strong proposal out there (which I support) to give<br>
enums optional properties, e.g.<br>
<br>
if let (x,y) = someFoo.Bar { ... }<br>
else if let (a,b) = someFoo.Baz { ... }<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> If that's not similar to Swift, please correct me.<br>
<br>
><br>
> On Tue, Jan 26, 2016 at 2:02 PM, Dave Abrahams via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> on Sun Jan 24 2016, Thorsten Seitz<br>
>> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> > Yes, I think they are a lot like sum (or union) types. In Ceylon enums<br>
>> > actually are modeled as union types (there is no specific enum<br>
>> > syntax).<br>
>><br>
>> Enums in Swift are exactly that; Ceylon chose the name "union;" we chose<br>
>> "enum." But Trent is saying that enum *cases* are like types.<br>
>><br>
>> > -Thorsten<br>
>> ><br>
>> >> Am 23.01.2016 um 19:57 schrieb Trent Nadeau via swift-evolution<br>
>> >> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
>> >><br>
>> >> While enum cases may not be types from a compiler perspective, I think<br>
>> they are from a user's level.<br>
>> >><br>
>> >> Consider:<br>
>> >><br>
>> >> enum MyError: ErrorType {<br>
>> >> case FileError(fileName: String)<br>
>> >> case SocketError(ipAddr: String, port: Int16)<br>
>> >> }<br>
>> >><br>
>> >> From a compiler perspective, it's a tagged union (one type), but for<br>
>> >> a user this is a set of disjoint types that happen to share the same<br>
>> >> space and have exhaustiveness checking, etc. It's a much more<br>
>> >> efficient and convenient version of multiple structs or tuples.<br>
>> >><br>
>> >> On Sat, Jan 23, 2016 at 1:49 PM, Joe Groff<br>
>> >> <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a><br>
>> >> <mailto:<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>>> wrote:<br>
>> >><br>
>> >> > On Jan 23, 2016, at 10:24 AM, Trent Nadeau<br>
>> >> > <<a href="mailto:tanadeau@gmail.com">tanadeau@gmail.com</a><br>
>> >> > <mailto:<a href="mailto:tanadeau@gmail.com">tanadeau@gmail.com</a>>> wrote:<br>
>> >> ><br>
>> >> > I think it makes sense for enum cases to be UpperCamelCase as they<br>
>> >> > can be thought of as scoped types (singleton types in the case of<br>
>> >> > cases with no associated types).<br>
>> >><br>
>> >> They aren't, though. I don't see much value in setting false<br>
>> expectations.<br>
>> >><br>
>> >> -Joe<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Trent Nadeau<br>
>> >> _______________________________________________<br>
>> >> swift-evolution mailing list<br>
>> >> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> >> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > swift-evolution mailing list<br>
>> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> --<br>
>> -Dave<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
<br>
--<br>
-Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>