<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please share you feedback :)</div><div class=""><br class=""></div><div class="">(Updating/rendered version: <a href="https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md" class="">https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md</a>)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">## Introduction</div><div class=""><br class=""></div><div class="">Argument labels are part of its function's declaration name. An enum case</div><div class="">declares a function that can be used to construct enum values. For cases with</div><div class="">associated values, their labels should be part of the constructor name, similar</div><div class="">to "normal" function and methods. In Swift 3, however, this is not true. This</div><div class="">proposal aim to change that.</div><div class=""><br class=""></div><div class="">## Motivation</div><div class=""><br class=""></div><div class="">After SE-0111, Swift function's fully qualified name consists of its base name</div><div class="">and all argument labels. As a example, one can invoke a function with its</div><div class="">fully name:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">func f(x: Int, y: Int) {}</div><div class=""><br class=""></div><div class="">f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)</div><div class="">```</div><div class=""><br class=""></div><div class="">This, however, is not true when enum cases with associated value were</div><div class="">constructed:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum Foo {</div><div class=""> case bar(x: Int, y: Int)</div><div class="">}</div><div class=""><br class=""></div><div class="">Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3</div><div class="">```</div><div class=""><br class=""></div><div class="">Here, the declared name for the case is `foo`; it has a tuple with two labeled</div><div class="">fields as its associated value. `x` and `y` aren't part of the case name. This</div><div class="">inconsistency may surprise some users.</div><div class=""><br class=""></div><div class="">Using tuple to implement associated value also limits us from certain layout</div><div class="">optimizations as each payload need to be a tuple first, as opposed to simply be</div><div class="">unique to the enum.</div><div class=""><br class=""></div><div class="">## Proposed solution</div><div class=""><br class=""></div><div class="">Include labels in enum case's declaration name. In the last example, `bar`'s</div><div class="">full name would become `bar(x:y:)`, `x` and `y` will no longer be labels in a</div><div class="">tuple. The compiler may also stop using tuple to represent associated values.</div><div class=""><br class=""></div><div class="">## Detailed design</div><div class=""><br class=""></div><div class="">When labels are present in enum cases, they are now part of case's declared name</div><div class="">instead of being labels for fields in a tuple. In details, when constructing an</div><div class="">enum value with the case name, label names must either be supplied in the</div><div class="">argument list it self, or as part of the full name.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.</div><div class="">Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.</div><div class="">Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.</div><div class="">```</div><div class=""><br class=""></div><div class="">Note that since the labels aren't part of a tuple, they no longer participate in</div><div class="">type checking, similar to functions:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">let f = Foo.bar // f has type (Int, Int) -> Foo</div><div class="">f(0, 0) // Okay!</div><div class="">f(x: 0, y: 0) // Won't compile.</div><div class="">```</div><div class=""><br class=""></div><div class="">## Source compatibility</div><div class=""><br class=""></div><div class="">Since type-checking rules on labeled tuple is stricter than that on function</div><div class="">argument labels, existing enum value construction by case name remain valid.</div><div class="">This change is source compatible with Swift 3.</div><div class=""><br class=""></div><div class="">## Effect on ABI stability and resilience</div><div class=""><br class=""></div><div class="">This change introduces compound names for enum cases, which affects their</div><div class="">declaration's name mangling.</div><div class=""><br class=""></div><div class="">The compiler may also choose to change enum payload's representation from tuple.</div><div class="">This may open up more space for improving enum's memory layout.</div><div class=""><br class=""></div><div class="">## Alternatives considered</div><div class=""><br class=""></div><div class="">Keep current behaviors, which means we live with the inconsistency.</div></div><div class=""><br class=""></div></body></html>