> On Jan 19, 2017, at 11:06 PM, Rien <r...@balancingrock.nl> wrote:
>
> Would this be allowed ?
>
> enum foo {
> case bar(num: Int)
> case bar(str: String)
> case vee(val: Bool)
> }
>
This is certainly an option…personally I think it's a little unconventional.
It's require new syntax for pattern matching, as you demonstrate in the next
question. We can hold off this possibility since adding it later wouldn't be a
breaking change.
> If so, would this still be allowed ?
>
> var a: foo = ...
> switch a {
> case vee: ...
> case bar: ...
> }
>
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Swiftrien
> Project: http://swiftfire.nl
>
>
>
>
>> On 19 Jan 2017, at 19:37, 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)
>>
>>
>> ## 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
