[swift-evolution] [Draft] Anonymous Enum Cases

[Daniel Duan]

Given that case overloading is out of scope, I'm guessing this is too.

> On Mar 15, 2017, at 2:59 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Are anonymous enum cases still in Swift 4 scope?
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 9. März 2017 um 15:00:48, Matthew Johnson via swift-evolution (swift-evolution at swift.org) schrieb:
> 
>> +1. Combining this with overloaded cases will be very nice for some kinds of enums.
>> 
>> Sent from my iPad
>> 
>> > On Mar 8, 2017, at 9:09 PM, Daniel Duan via swift-evolution <swift-evolution at swift.org> wrote:
>> > 
>> > Hi all,
>> > 
>> > During review for the first revision of SE-0155, Dave Abraham suggested that we should allow enum cases without base names. So here’s a (rough) draft of a proposal for this feature. Please read and share your thoughts!
>> > 
>> > # Anonymous Enum Cases
>> > 
>> > * Proposal: [SE-NNNN](NNNN-anonymous-enum-cases.md)
>> > * Authors: [Daniel Duan](https://github.com/dduan)
>> > * Review Manager: TBD
>> > * Status: **Awaiting review**
>> > 
>> > ## Introduction
>> > 
>> > This proposal adds anonymous cases to Swift's enum.
>> > 
>> > ## Motivation
>> > 
>> > Naming things is a tough task for programmer. This is one merit of features such
>> > as anonymous function and tuples: users can use them in a limited scope and skip
>> > the mind burden of coming up with names. We can expand this convenience to enums
>> > by allowing user to declare, construct and pattern match anonymous cases.
>> > 
>> > ## Proposed solution
>> > 
>> > Add anonymous cases to Swift's enum.
>> > 
>> > ## Detailed design
>> > 
>> > Anonymous enums can be declared with this syntax:
>> > 
>> > ```swift
>> > enum Foo {
>> > case (Int)
>> > case (label0: Int, label1: String)
>> > }
>> > ```
>> > 
>> > Anonymous case without any associated values is not allowed.
>> > 
>> > Anonymous case values can be constructed with constructors with the enum's name
>> > being their base name. Following the example:
>> > 
>> > ```swift
>> > Foo(42) // constructs `Foo` case corresponding to `case (Int)`
>> > Foo(label0: 0, labe1: "hello") // value of type Foo, 2nd case.
>> > Foo(label0: label1:)(0, "hello") // constructs the same value, SE-0155 syntax
>> > ```
>> > 
>> > For pattern matching, rules remain the same as regular cases, execpt, naturally,
>> > the base name shall be skipped.
>> > 
>> > ```swift
>> > case .(let x) = Foo(42) // x has value 42
>> > case .(label0: let a, label1: let b) = Foo(label0: 0, label1: "hello") // ok
>> > ```
>> > 
>> > ## Source compatibility
>> > 
>> > This is additive. It's fully source compatible with Swift 3.
>> > 
>> > ## Effect on ABI stability
>> > 
>> > This feature adds new possibilities to symbols exposed by enum declarations.
>> > 
>> > ## Effect on API resilience
>> > 
>> > ## Alternatives considered
>> > 
>> > It may seem "regular" to make user use `_` in place of base name in
>> > declarations. The author think that's a perspective that only makes sense for
>> > language designer/compiler implementors. To a user, the syntax chosen in this
>> > proposal is clear and succinct.
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org
>> > 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
> 
> _______________________________________________
> 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/20170315/598c173b/attachment.html>