[swift-evolution] [Review] SE-0023 API Design Guidelines
Trent Nadeau
tanadeau at gmail.com
Tue Jan 26 20:09:29 CST 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/e44a669b/attachment.html>
More information about the swift-evolution
mailing list