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

[Dave Abrahams]

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