<div dir="ltr">I&#39;ll summarize my thoughts for now, after thinking about it for a bit longer:<div><br></div><div>Plusses:</div><div>+ In some cases it&#39;s nicer to have the ability to group functionality at each case rather than spread across methods lower in the type definition. I&#39;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></div><div>+ This is the cleanest syntax I&#39;ve seen proposed for this idea.<br></div><div><br></div><div>Things that worry me:</div><div>– It&#39;s a new way to express the same idea without necessarily *simplifying* it in terms of code complexity.</div><div>– 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>– 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&#39;s quite a departure from the way we model these concepts.</div><div>– 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><br></div><div>```</div><div><div>enum Foo {</div><div>  var description: String {</div><div>    switch self {</div><div>    case .bar: return &quot;bar&quot;</div><div>    case .baz: return &quot;baz&quot;</div><div>    default: return &quot;&quot;</div><div>  }</div><div>  </div><div>  case bar</div><div>  case baz</div><div>  case quux {</div><div>    var description: String { return &quot;quux&quot; }</div><div>  }</div><div>}</div></div><div>```</div><div><br></div><div>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><br></div><div>```</div><div><div>  var description: String {</div><div>    switch self {</div><div>    case .quux: return &quot;quux&quot;</div><div>    default:</div><div>      switch self {</div><div>      case .bar: return &quot;bar&quot;</div><div>      case .baz: return &quot;baz&quot;</div><div>      default: return &quot;&quot;</div><div>    }</div><div>  }</div></div><div>```</div><div><br></div><div>...which produces the expected output, but the generated code might not be ideal.</div><div><br></div><div>That makes me question whether we should allow default implementations at all. If we didn&#39;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><br></div><div>So... I guess I&#39;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&#39;ve written, but I&#39;m hedging a bit conservatively because of those concerns above.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 11, 2017 at 7:08 AM David Sweeris &lt;<a href="mailto:davesweeris@mac.com">davesweeris@mac.com</a>&gt; wrote:<br></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 &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;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 &quot;in addition to&quot; and not &quot;instead of&quot;, the only downside I can see to allowing this is a bit of &quot;language bloat&quot;, which doesn&#39;t particularly bother me. I don&#39;t know how hard it would be for the compiler to sort out which &quot;mode&quot; 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&#39;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>