<div dir="ltr">Obvious +1. Since enum cases with payloads are essentially static factory functions and you can get references to them just like any other function, those references should follow the same rules as a regular function.<br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 19, 2017 at 10:37 AM Daniel Duan via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">Hi all,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please share you feedback :)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(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="gmail_msg" target="_blank">https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/NNNN-Compound-Names-For-Enum-Cases.md</a>)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">## Introduction</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Argument labels are part of its function's declaration name. An enum case</div><div class="gmail_msg">declares a function that can be used to construct enum values. For cases with</div><div class="gmail_msg">associated values, their labels should be part of the constructor name, similar</div><div class="gmail_msg">to "normal" function and methods. In Swift 3, however, this is not true. This</div><div class="gmail_msg">proposal aim to change that.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Motivation</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">After SE-0111, Swift function's fully qualified name consists of its base name</div><div class="gmail_msg">and all argument labels. As a example, one can invoke a function with its</div><div class="gmail_msg">fully name:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```swift</div><div class="gmail_msg">func f(x: Int, y: Int) {}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This, however, is not true when enum cases with associated value were</div><div class="gmail_msg">constructed:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```swift</div><div class="gmail_msg">enum Foo {</div><div class="gmail_msg"> case bar(x: Int, y: Int)</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Here, the declared name for the case is `foo`; it has a tuple with two labeled</div><div class="gmail_msg">fields as its associated value. `x` and `y` aren't part of the case name. This</div><div class="gmail_msg">inconsistency may surprise some users.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Using tuple to implement associated value also limits us from certain layout</div><div class="gmail_msg">optimizations as each payload need to be a tuple first, as opposed to simply be</div><div class="gmail_msg">unique to the enum.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Proposed solution</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Include labels in enum case's declaration name. In the last example, `bar`'s</div><div class="gmail_msg">full name would become `bar(x:y:)`, `x` and `y` will no longer be labels in a</div><div class="gmail_msg">tuple. The compiler may also stop using tuple to represent associated values.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Detailed design</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">When labels are present in enum cases, they are now part of case's declared name</div><div class="gmail_msg">instead of being labels for fields in a tuple. In details, when constructing an</div><div class="gmail_msg">enum value with the case name, label names must either be supplied in the</div><div class="gmail_msg">argument list it self, or as part of the full name.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```swift</div><div class="gmail_msg">Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.</div><div class="gmail_msg">Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.</div><div class="gmail_msg">Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Note that since the labels aren't part of a tuple, they no longer participate in</div><div class="gmail_msg">type checking, similar to functions:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">```swift</div><div class="gmail_msg">let f = Foo.bar // f has type (Int, Int) -> Foo</div><div class="gmail_msg">f(0, 0) // Okay!</div><div class="gmail_msg">f(x: 0, y: 0) // Won't compile.</div><div class="gmail_msg">```</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Source compatibility</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Since type-checking rules on labeled tuple is stricter than that on function</div><div class="gmail_msg">argument labels, existing enum value construction by case name remain valid.</div><div class="gmail_msg">This change is source compatible with Swift 3.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Effect on ABI stability and resilience</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This change introduces compound names for enum cases, which affects their</div><div class="gmail_msg">declaration's name mangling.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The compiler may also choose to change enum payload's representation from tuple.</div><div class="gmail_msg">This may open up more space for improving enum's memory layout.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">## Alternatives considered</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Keep current behaviors, which means we live with the inconsistency.</div></div><div class="gmail_msg"><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>