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 > <[email protected]> wrote: > > Great, thanks. Love it :) > > +1 > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Februar 2017 um 14:39:43, Daniel Duan ([email protected] > <mailto:[email protected]>) schrieb: > >> This has been answered in various forms in the thread. Short answer: yes. >> >> On Feb 2, 2017, at 2:05 AM, Adrian Zubarev <[email protected] >> <mailto:[email protected]>> 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 >>> ([email protected] <mailto:[email protected]>) 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
