This looks totally reasonable to me. A couple of comments:
1) Because this proposal is breaking the link between the associated value of
an enum case and tuple types, I think it should spell out the rules that switch
statements will use when matching an enum value against a a case with an
associated value. Some kind of rules fell out of them being treated as tuple
types, but they might not be what we want.
2) I wouldn’t blame you if you wanted to slip in default arguments for
associated values here, because this is really making enum cases with
associated values much more function-like
- Doug
> On Jan 19, 2017, at 10:37 AM, Daniel Duan via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Hi all,
>
> Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please
> share you feedback :)
>
> (Updating/rendered version:
> https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md
>
> <https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md>)
>
>
> ## Introduction
>
> Argument labels are part of its function's declaration name. An enum case
> declares a function that can be used to construct enum values. For cases with
> associated values, their labels should be part of the constructor name,
> similar
> to "normal" function and methods. In Swift 3, however, this is not true. This
> proposal aim to change that.
>
> ## Motivation
>
> After SE-0111, Swift function's fully qualified name consists of its base name
> and all argument labels. As a example, one can invoke a function with its
> fully name:
>
> ```swift
> func f(x: Int, y: Int) {}
>
> f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
> ```
>
> This, however, is not true when enum cases with associated value were
> constructed:
>
> ```swift
> enum Foo {
> case bar(x: Int, y: Int)
> }
>
> Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
> ```
>
> Here, the declared name for the case is `foo`; it has a tuple with two labeled
> fields as its associated value. `x` and `y` aren't part of the case name. This
> inconsistency may surprise some users.
>
> Using tuple to implement associated value also limits us from certain layout
> optimizations as each payload need to be a tuple first, as opposed to simply
> be
> unique to the enum.
>
> ## Proposed solution
>
> Include labels in enum case's declaration name. In the last example, `bar`'s
> full name would become `bar(x:y:)`, `x` and `y` will no longer be labels in a
> tuple. The compiler may also stop using tuple to represent associated values.
>
> ## Detailed design
>
> When labels are present in enum cases, they are now part of case's declared
> name
> instead of being labels for fields in a tuple. In details, when constructing
> an
> enum value with the case name, label names must either be supplied in the
> argument list it self, or as part of the full name.
>
> ```swift
> Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
> Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
> Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
> ```
>
> Note that since the labels aren't part of a tuple, they no longer participate
> in
> type checking, similar to functions:
>
> ```swift
> let f = Foo.bar // f has type (Int, Int) -> Foo
> f(0, 0) // Okay!
> f(x: 0, y: 0) // Won't compile.
> ```
>
> ## Source compatibility
>
> Since type-checking rules on labeled tuple is stricter than that on function
> argument labels, existing enum value construction by case name remain valid.
> This change is source compatible with Swift 3.
>
> ## Effect on ABI stability and resilience
>
> This change introduces compound names for enum cases, which affects their
> declaration's name mangling.
>
> The compiler may also choose to change enum payload's representation from
> tuple.
> This may open up more space for improving enum's memory layout.
>
> ## Alternatives considered
>
> Keep current behaviors, which means we live with the inconsistency.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
