[swift-evolution] [Review] SE-0023 API Design Guidelines

Thorsten Seitz tseitz42 at icloud.com
Wed Jan 27 00:07:20 CST 2016


That Ceylon example is exactly what I've been thinking of, too.

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).

-Thorsten 

> Am 27.01.2016 um 03:09 schrieb Trent Nadeau via swift-evolution <swift-evolution at swift.org>:
> 
> I think I understand where you're coming from now in that you can think of:
> 
> enum Foo {
>     case Bar(x: Int, y: Int)
>     case Baz(a: Double, b: Double)
> }
> 
> as:
> 
> struct Foo {
>     let Bar: (x: Int, y: Int)
>     let Baz: (a: Double, b: Double)
> }
> 
> with special handling for storage and pattern matching.
> 
> I was thinking of it more in terms of mapping to:
> 
> struct Foo {
>     typealias Bar = (x: Int, y: Int)
>     typealias Baz = (a: Double, b: Double)
> 
>     let storage: MagicStorageOfMaxSize
> }
> 
> with special handling for type use and pattern matching.
> 
> 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:
> 
> abstract class Node() of Leaf | Branch {}
> 
> class Leaf(shared Object element) 
>         extends Node() {}
> 
> class Branch(shared Node left, shared Node right) 
>         extends Node() {}
> 
>> On Tue, Jan 26, 2016 at 7:49 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> on Tue Jan 26 2016, Trent Nadeau <swift-evolution at swift.org> wrote:
>> 
>> > I should clarify. I mean that they're like types in that they have a
>> > unique scoped name with fields.
>> 
>> struct X {
>>   static var y: Int = 3
>> }
>> 
>> X.y has a unique scoped name.  What's all this about fields?  I don't
>> understand that part.
>> 
>> > A union with cases with associated values is a sum types of product
>> > types. Obviously, they can't be used like "real" types as formal
>> > parameters, etc.
>> >
>> > I don't see them as values or initializers but very constrained types. For
>> > instance, in C you could have something like:
>> >
>> > struct Foo {
>> >
>> >     int tag;
>> >
>> >     union {
>> >
>> >         struct Bar {
>> >
>> >            int x;
>> >
>> >            int y;
>> >
>> >         } bar;
>> >
>> >         struct Baz {
>> >
>> >           double a;
>> >
>> >           double b;
>> >
>> >         } baz;
>> >
>> >     } data;
>> >
>> > };
>> >
>> > which would be equivalent to Swift's:
>> >
>> > enum Foo {
>> >     case Bar(x: Int, y: Int)
>> >     case Baz(a: Double, b: Double)
>> > }
>> >
>> > Bar and Baz in the C code above are actual types just unusable outside of
>> > the sum type (tagged union).
>> 
>> The fact that an anonymous union in C hides the types declared within is
>> just a quirk of that language.  You didn't even need to name Bar and Baz
>> in the `C' code.  The Bar and Baz in your swift code are more similar to
>> bar and baz (lowercase) as they are required in order to access members
>> of the sum.
>> 
>> FWIW, there's a strong proposal out there (which I support) to give
>> enums optional properties, e.g.
>> 
>>       if let (x,y) = someFoo.Bar { ... }
>>       else if let (a,b) = someFoo.Baz { ... }
>> 
>> 
>> 
>> > If that's not similar to Swift, please correct me.
>> 
>> >
>> > On Tue, Jan 26, 2016 at 2:02 PM, Dave Abrahams via swift-evolution <
>> > swift-evolution at swift.org> wrote:
>> >
>> >>
>> >> on Sun Jan 24 2016, Thorsten Seitz
>> >> <swift-evolution at swift.org> wrote:
>> >>
>> >> > Yes, I think they are a lot like sum (or union) types. In Ceylon enums
>> >> > actually are modeled as union types (there is no specific enum
>> >> > syntax).
>> >>
>> >> Enums in Swift are exactly that; Ceylon chose the name "union;" we chose
>> >> "enum."  But Trent is saying that enum *cases* are like types.
>> >>
>> >> > -Thorsten
>> >> >
>> >> >> Am 23.01.2016 um 19:57 schrieb Trent Nadeau via swift-evolution
>> >> >> <swift-evolution at swift.org>:
>> >> >>
>> >> >> While enum cases may not be types from a compiler perspective, I think
>> >> they are from a user's level.
>> >> >>
>> >> >> Consider:
>> >> >>
>> >> >> enum MyError: ErrorType {
>> >> >>     case FileError(fileName: String)
>> >> >>     case SocketError(ipAddr: String, port: Int16)
>> >> >> }
>> >> >>
>> >> >> From a compiler perspective, it's a tagged union (one type), but for
>> >> >> a user this is a set of disjoint types that happen to share the same
>> >> >> space and have exhaustiveness checking, etc. It's a much more
>> >> >> efficient and convenient version of multiple structs or tuples.
>> >> >>
>> >> >> On Sat, Jan 23, 2016 at 1:49 PM, Joe Groff
>> >> >> <jgroff at apple.com
>> >> >> <mailto:jgroff at apple.com>> wrote:
>> >> >>
>> >> >> > On Jan 23, 2016, at 10:24 AM, Trent Nadeau
>> >> >> > <tanadeau at gmail.com
>> >> >> > <mailto:tanadeau at gmail.com>> wrote:
>> >> >> >
>> >> >> > I think it makes sense for enum cases to be UpperCamelCase as they
>> >> >> > can be thought of as scoped types (singleton types in the case of
>> >> >> > cases with no associated types).
>> >> >>
>> >> >> They aren't, though. I don't see much value in setting false
>> >> expectations.
>> >> >>
>> >> >> -Joe
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Trent Nadeau
>> >> >> _______________________________________________
>> >> >> swift-evolution mailing list
>> >> >> swift-evolution at swift.org
>> >> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >> >
>> >> > _______________________________________________
>> >> > swift-evolution mailing list
>> >> > swift-evolution at swift.org
>> >> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>
>> >> --
>> >> -Dave
>> >>
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>
>> 
>> --
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Trent Nadeau
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160127/3724798b/attachment.html>


More information about the swift-evolution mailing list