[swift-evolution] [draft] Compound Names For Enum Cases

[Dennis Weissmann]

I'm also +1 on this, wanted this for a long time :)

- Dennis

> On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Great, thanks. Love it :) 
> 
> +1 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Februar 2017 um 14:39:43, Daniel Duan (daniel at duan.org <mailto:daniel at duan.org>) schrieb:
> 
>> This has been answered in various forms in the thread. Short answer: yes.
>> 
>> On Feb 2, 2017, at 2:05 AM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
>> 
>>> Is that correct that this proposal will add some sort of overloading enum cases by different labels?
>>> 
>>> enum Foo {
>>>     case foo(a: Int)
>>>     case foo(a: Int, b: Int)
>>> }   
>>> Is Foo a valid enum after this proposal?
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 19. Januar 2017 um 19:37:50, Daniel Duan via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>> 
>>>> 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 at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170203/2d36d0b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3585 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170203/2d36d0b6/attachment.p7s>