<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=""><div class=""><div class="">Fantastic points, all. Let me reply to a few.</div><div class=""><br class=""></div><div class="">First, the odd situations you mentioned with the defaults were spot on. I had seen them, and thought a bit about it, but having you write it out in code made it obvious that they're pretty harmful. I've removed defaults entirely (see the updated Alternatives and Errors sections). This is actually a really good indicator of whether you should use this syntax or not. If you'll save a noticeable amount of space by using a default, then this isn't the syntax for your situation.</div><div class=""><br class=""></div><div class="">To make that more obvious, I've added a Mixed Use Example (<a href="https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562#mixed-use-example" class="">https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562#mixed-use-example</a>) showing how simple it is to use the existing syntax when you have a default and a small number of exceptions, alongside the case block syntax for things that are unique for each case. So, to summarize, I think that forcing the additional code for each case is a good thing so that this syntax remains the exception used when needed, instead of becoming the rule.</div><div class=""><br class=""></div><div class="">Now to your other points. The intent isn't to alter the amount of code required to accomplish the task (code *complexity*), but to simplify *maintenance and understanding* by allowing you to organize the code either by property or by case (according to the merits of the code and your judgement). Indeed, I try to highlight in the proposal that this usually _increases_ code verbosity slightly in favor of the readability gained by shifting the code layout.</div><div class=""><br class=""></div><div class="">Finally, to your point about attaching properties to values (also echoed in David's musings about tagged unions vs Swift enums), it is different, but I'm not sure of a cleaner way to group all the code related to a single case for complex enums. In another light, no other type in Swift makes such heavy use of `switch` statements as a mechanism to organize code, and so this starts to make enum code look more like the rest of the code you find in Swift projects, which could be a good thing for long-term readability.</div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 11, 2017, at 9:22 AM, 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'll summarize my thoughts for now, after thinking about it for a bit longer:<div class=""><br class=""></div><div class="">Plusses:</div><div class="">+ In some cases it's nicer to have the ability to group functionality at each case rather than spread across methods lower in the type definition. I've written enums that were like state machines where being able to have the next state transition and other associated data grouped with the case would have made the code a bit cleaner, IMO.<br class=""></div><div class="">+ This is the cleanest syntax I've seen proposed for this idea.<br class=""></div><div class=""><br class=""></div><div class="">Things that worry me:</div><div class="">– It's a new way to express the same idea without necessarily *simplifying* it in terms of code complexity.</div><div class="">– It adds a fair amount of complexity to the compiler, to build the implicit self-switch and merge the implementations for each partial property/function.</div><div class="">– It would be the first time, I believe, in Swift where properties/method implementations are attached to *values* rather than just to the *type*. That's quite a departure from the way we model these concepts.</div><div class="">– The use of the type-defined implementation as the default when a case-defined implementation is omitted can lead to some bizarre combinations, which I think need to be addressed in the proposal. Consider this:</div><div class=""><br class=""></div><div class="">```</div><div class=""><div class="">enum Foo {</div><div class=""> var description: String {</div><div class=""> switch self {</div><div class=""> case .bar: return "bar"</div><div class=""> case .baz: return "baz"</div><div class=""> default: return ""</div><div class=""> }</div><div class=""> </div><div class=""> case bar</div><div class=""> case baz</div><div class=""> case quux {</div><div class=""> var description: String { return "quux" }</div><div class=""> }</div><div class="">}</div></div><div class="">```</div><div class=""><br class=""></div><div class="">Should the user be able to omit the `default` case because everything is exhaustively covered without it? *Conceptually* yes, but that would require the compiler to analyze the switch statement inside `description` and understand that, which is probably not feasible for anything but the simplest examples (and perhaps not even for those). Otherwise, it would presumably transform the implementation to this:</div><div class=""><br class=""></div><div class="">```</div><div class=""><div class=""> var description: String {</div><div class=""> switch self {</div><div class=""> case .quux: return "quux"</div><div class=""> default:</div><div class=""> switch self {</div><div class=""> case .bar: return "bar"</div><div class=""> case .baz: return "baz"</div><div class=""> default: return ""</div><div class=""> }</div><div class=""> }</div></div><div class="">```</div><div class=""><br class=""></div><div class="">...which produces the expected output, but the generated code might not be ideal.</div><div class=""><br class=""></div><div class="">That makes me question whether we should allow default implementations at all. If we didn't allow it, we potentially require the user to write *more* code because they would have to duplicate the defaults under each case separately. But it opens a door to potential confusion if we do allow them.</div><div class=""><br class=""></div><div class="">So... I guess I'm on the fence right now. I want to support this from the point of view that syntactically it would improve the quality of some of the enums I've written, but I'm hedging a bit conservatively because of those concerns above.</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jan 11, 2017 at 7:08 AM David Sweeris <<a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Jan 11, 2017, at 08:48, Derrick Ho 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"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Interesting proposal Tim. So instead of repeating the enum cases multiple times we repeat the functions multiple times?<br class="gmail_msg"><br class="gmail_msg">I feel like this merely flipping the complexity but not really getting rid of it.</div></blockquote><br class="gmail_msg"></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">I <i class="gmail_msg">think</i> you have correctly summarized the proposal.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The complexity can't be gotten rid of (except maybe with macros... depending on the details, of course). Sometimes viewing the same thing from a different angle can be helpful. As long as this syntax is "in addition to" and not "instead of", the only downside I can see to allowing this is a bit of "language bloat", which doesn't particularly bother me. I don't know how hard it would be for the compiler to sort out which "mode" it should parse the enum in, though, especially since you might want to write some parts in the regular way and some parts in this new way.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">So... I guess I'm +1, pending someone who knows more about compiler internals weighing in on implementation implications.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Dave Sweeris</div></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>