<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="">OK. I've taken the most recent changes from this thread and put together a draft for a proposal.<div class=""><br class=""></div><div class=""><a href="https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562" class="">https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562</a></div><div class=""><br class=""></div><div class="">I'd appreciate your review, especially to ensure I've covered all the important scenarios. I've taken the 3 associated value scenarios (none, unlabeled, labeled) and shown them in each example (calculated value, func, default, error). I've included the raw text below, without any syntax highlighting.</div><div class=""><br class=""></div><div class="">My big question is: does the error case in the last example affect ABI requirements, in order to display the error at the correct case line? I assume it doesn't, but that's an area I don't know well.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><div class="">===============</div><div class=""><br class=""></div><div class=""><div class=""># Enum Case Blocks</div><div class=""><br class=""></div><div class="">* Proposal: SE-XXXX</div><div class="">* Authors: [Tim Shadel](<a href="https://github.com/timshadel" class="">https://github.com/timshadel</a>)</div><div class="">* Review Manager: TBD</div><div class="">* Status: **TBD**</div><div class=""><br class=""></div><div class="">## Motivation</div><div class=""><br class=""></div><div class="">Add an optional syntax to declare all code related to a single `case` in one spot. For complex `enum`s, this makes it easier to ensure that all the pieces mesh coherently across that one case, and to review all logic associated with a single `case`. This syntax is frequently more verbose in order to achieve a more coherent code structure, so its use will be most valuable in complex enums.</div><div class=""><br class=""></div><div class="">Swift-evolution thread: [Consolidate Code for Each Case in Enum](<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029966.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029966.html</a>)</div><div class=""><br class=""></div><div class="">## Proposed solution</div><div class=""><br class=""></div><div class="">Allow an optional block directly after the `case` declaration on an `enum`. Construct a hidden `switch self` statement for each calculated value or `func` defined in any case block. Use the body of each such calculated value in the hidden `switch self` under the appropriate case. Because switch statements must be exhaustive, the calculated value or `func` must be defined in each case block or have a `default` value to avoid an error. Defining the `func` or calculated value outside a case block defines the default case for the `switch self`. To reference an associated value within any of the items in a case block requires the value be labeled, or use a new syntax `case(_ label: Type)` to provide a local-only name for the associated value.</div><div class=""><br class=""></div><div class="">## Examples</div><div class=""><br class=""></div><div class="">All examples below are evolutions of this simple enum.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState {</div><div class=""> case invalid</div><div class=""> case expired(Date)</div><div class=""> case validated(token: String)</div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">### Basic example</div><div class=""><br class=""></div><div class="">First, let's add `CustomStringConvertible` conformance to our enum.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid {</div><div class=""> var description: String { return "Authentication invalid." }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> case expired(_ expiration: Date) {</div><div class=""> var description: String { return "Authentication expired at \(expiration)." }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> case validated(token: String) {</div><div class=""> var description: String { return "The authentication token is \(token)." }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">This is identical to the following snippet of Swift 3 code:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid</div><div class=""> case expired(Date)</div><div class=""> case validated(token: String)</div><div class=""><br class=""></div><div class=""> var description: String {</div><div class=""> switch self {</div><div class=""> case invalid:</div><div class=""> return "Authentication invalid."</div><div class=""> case let expired(expiration):</div><div class=""> return "Authentication expired at \(expiration)."</div><div class=""> case let validated(token):</div><div class=""> return "The authentication token is \(token)."</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">### Extended example</div><div class=""><br class=""></div><div class="">Now let's have our enum conform to this simple `State` protocol, which expects each state to be able to update itself in reaction to an `Event`. This example begins to show how this optional syntax give better coherence to the enum code by placing code related to a single case in a single enclosure.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">protocol State {</div><div class=""> mutating func react(to event: Event)</div><div class="">}</div><div class=""><br class=""></div><div class="">enum AuthenticationState: State, CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid {</div><div class=""> var description: String { return "Authentication invalid." }</div><div class=""><br class=""></div><div class=""> mutating func react(to event: Event) {</div><div class=""> switch event {</div><div class=""> case let login as UserLoggedIn:</div><div class=""> self = .validated(token: login.token)</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> case expired(_ expiration: Date) {</div><div class=""> var description: String { return "Authentication expired at \(expiration)." }</div><div class=""><br class=""></div><div class=""> mutating func react(to event: Event) {</div><div class=""> switch event {</div><div class=""> case let refreshed as TokenRefreshed:</div><div class=""> self = .validated(token: refreshed.token)</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> case validated(token: String) {</div><div class=""> var description: String { return "The authentication token is \(token)." }</div><div class=""><br class=""></div><div class=""> mutating func react(to event: Event) {</div><div class=""> switch event {</div><div class=""> case let expiration as TokenExpired:</div><div class=""> print("Expiring token: \(token)")</div><div class=""> self = .expired(expiration.date)</div><div class=""> case _ as TokenRejected:</div><div class=""> self = .invalid</div><div class=""> case _ as UserLoggedOut:</div><div class=""> self = .invalid</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">This becomes identical to the following Swift 3 code:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: State, CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid</div><div class=""> case expired(Date)</div><div class=""> case validated(token: String)</div><div class=""><br class=""></div><div class=""> var description: String {</div><div class=""> switch self {</div><div class=""> case invalid:</div><div class=""> return "Authentication invalid."</div><div class=""> case let expired(expiration):</div><div class=""> return "Authentication expired at \(expiration)."</div><div class=""> case let validated(token):</div><div class=""> return "The authentication token is \(token)."</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class=""> mutating func react(to event: Event) {</div><div class=""> switch self {</div><div class=""> case invalid: {</div><div class=""> switch event {</div><div class=""> case let login as UserLoggedIn:</div><div class=""> self = .validated(token: login.token)</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> case let expired(expiration) {</div><div class=""> switch event {</div><div class=""> case let refreshed as TokenRefreshed:</div><div class=""> self = .validated(token: refreshed.token)</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> case let validated(token) {</div><div class=""> switch event {</div><div class=""> case let expiration as TokenExpired:</div><div class=""> print("Expiring token: \(token)")</div><div class=""> self = .expired(expiration.date)</div><div class=""> case _ as TokenRejected:</div><div class=""> self = .invalid</div><div class=""> case _ as UserLoggedOut:</div><div class=""> self = .invalid</div><div class=""> default:</div><div class=""> break</div><div class=""> }</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">### Default case example</div><div class=""><br class=""></div><div class="">Let's go back to the simple example to demonstrate declaring a default case.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> var description: String { return "" }</div><div class=""><br class=""></div><div class=""> case invalid</div><div class=""> case expired(Date)</div><div class=""> case validated(token: String) {</div><div class=""> var description: String { return "The authentication token is \(token)." }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">Is identical to this Swift 3 code:</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid</div><div class=""> case expired(Date)</div><div class=""> case validated(token: String)</div><div class=""><br class=""></div><div class=""> var description: String {</div><div class=""> switch self {</div><div class=""> case let validated(token):</div><div class=""> return "The authentication token is \(token)."</div><div class=""> default:</div><div class=""> return ""</div><div class=""> }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">### Error example</div><div class=""><br class=""></div><div class="">Finally, here's what happens when a case fails to add a block when no default is defined.</div><div class=""><br class=""></div><div class="">```swift</div><div class="">enum AuthenticationState: CustomStringConvertible {</div><div class=""><br class=""></div><div class=""> case invalid <<< error: description must be exhaustively defined. Missing block for case .invalid.</div><div class=""><br class=""></div><div class=""> case expired(Date) <<< error: description must be exhaustively defined. Missing block for case .expired.</div><div class=""><br class=""></div><div class=""> case validated(token: String) {</div><div class=""> var description: String { return "The authentication token is \(token)." }</div><div class=""> }</div><div class=""><br class=""></div><div class="">}</div><div class="">```</div><div class=""><br class=""></div><div class="">## Source compatibility</div><div class=""><br class=""></div><div class="">No source is deprecated in this proposal, so source compatibility should be preserved.</div><div class=""><br class=""></div><div class="">## Effect on ABI stability</div><div class=""><br class=""></div><div class="">Because the generated switch statement should be identical to one that can be generated with Swift 3, I don't foresee effect on ABI stability.</div><div class=""><br class=""></div><div class="">Question: does the error case above affect ABI requirements, in order to display the error at the correct case line?</div><div class=""><br class=""></div><div class="">## Alternatives considered</div><div class=""><br class=""></div><div class="">Use of the `extension` keyword was discussed and quickly rejected for numerous reasons.</div></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 9, 2017, at 2:22 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="">tony.allevato@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I like that approach a lot (and it would be nice to use separate labels vs. argument names in the case where they do have labels, too).<div class=""><br class=""></div><div class="">Enum cases with associated values are really just sugar for static methods on the enum type *anyway* with the added pattern matching abilities, so unifying the syntax seems like a positive direction to go in.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jan 9, 2017 at 1:20 PM Tim Shadel <<a href="mailto:timshadel@gmail.com" class="">timshadel@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, that's much nicer than what I just sent! :-D<br class="gmail_msg">
<br class="gmail_msg">
> On Jan 9, 2017, at 2:16 PM, Sean Heber <<a href="mailto:sean@fifthace.com" class="gmail_msg" target="_blank">sean@fifthace.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> I can’t speak for Tim, but I’d suggest just unifying the case syntax with functions so they become:<br class="gmail_msg">
><br class="gmail_msg">
> case foo(_ thing: Int)<br class="gmail_msg">
><br class="gmail_msg">
> And if you don’t actually need to ever *use* it by name in your enum properties/functions (if you even have any), then you could leave it out and write it like it is now, but that’d become “sugar”:<br class="gmail_msg">
><br class="gmail_msg">
> case foo(Int)<br class="gmail_msg">
><br class="gmail_msg">
> l8r<br class="gmail_msg">
> Sean<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On Jan 9, 2017, at 3:11 PM, Tony Allevato <<a href="mailto:tony.allevato@gmail.com" class="gmail_msg" target="_blank">tony.allevato@gmail.com</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> Ah, my apologies—the syntax highlighting in the thread was throwing off my e-mail client and I was having trouble reading it.<br class="gmail_msg">
>><br class="gmail_msg">
>> Associated values don't necessarily have to have names: I can write "case .foo(Int)". Since your examples use the associated value label as the name of the value inside the body, how would you handle those label-less values?<br class="gmail_msg">
>><br class="gmail_msg">
>><br class="gmail_msg">
>> On Mon, Jan 9, 2017 at 1:06 PM Tim Shadel <<a href="mailto:timshadel@gmail.com" class="gmail_msg" target="_blank">timshadel@gmail.com</a>> wrote:<br class="gmail_msg">
>> There are examples of associated values in the proposed syntax. Which parts should I provide more detail on?<br class="gmail_msg">
>><br class="gmail_msg">
>>> On Jan 9, 2017, at 1:43 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>> While I do like the consolidated syntax more than most of the alternatives I've seen to address this problem, any proposed solution also needs to address how it would work with cases that have associated values. That complicates the syntax somewhat.<br class="gmail_msg">
>>><br class="gmail_msg">
>>><br class="gmail_msg">
>>> On Mon, Jan 9, 2017 at 12:37 PM Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>><br class="gmail_msg">
>>>> On Jan 9, 2017, at 2:28 PM, Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>><br class="gmail_msg">
>>>>> On 9 janv. 2017, at 10:54, Tim Shadel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>>>>><br class="gmail_msg">
>>>>> Enums get large, and they get complicated because the code for each case gets sliced up and scattered across many functions. It becomes a "one of these things is not like the other" situation because writing functions inside enums is unlike writing functions in any other part of Swift code.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> The problem I see with this is that enums and their functions inherently multiply each other. If I have 3 cases and 3 functions or properties, there are 9 implementation details, no matter how they're organized. There can be 3 functions/properties, each with a 3-case switch, or there can be 3 enum cases each with 3 strange, partial functions/properties.<br class="gmail_msg">
>>>><br class="gmail_msg">
>>>> I can see why someone might prefer one over the other, but is either way truly better? The current way this works at least has the merit of not requiring a special dialect for enums.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> I’m not sure how to argue this, but I feel pretty strongly that something more like this proposed organization *is* actually better. That said, I do not think this conflicts with the current design of enums, however, so this is likely purely additive. The current design makes some situations almost comically verbose and disorganized, IMO, but it *is* right for other situations. We may want to have both.<br class="gmail_msg">
>>><br class="gmail_msg">
>>> l8r<br class="gmail_msg">
>>> Sean<br class="gmail_msg">
>>> _______________________________________________<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">
>>> _______________________________________________<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">
>><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>