[swift-evolution] Consolidate Code for Each Case in Enum

[Tony Allevato]

I'll summarize my thoughts for now, after thinking about it for a bit
longer:

Plusses:
+ 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.
+ This is the cleanest syntax I've seen proposed for this idea.

Things that worry me:
– It's a new way to express the same idea without necessarily *simplifying*
it in terms of code complexity.
– 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.
– 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.
– 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:

```
enum Foo {
  var description: String {
    switch self {
    case .bar: return "bar"
    case .baz: return "baz"
    default: return ""
  }

  case bar
  case baz
  case quux {
    var description: String { return "quux" }
  }
}
```

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:

```
  var description: String {
    switch self {
    case .quux: return "quux"
    default:
      switch self {
      case .bar: return "bar"
      case .baz: return "baz"
      default: return ""
    }
  }
```

...which produces the expected output, but the generated code might not be
ideal.

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.

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.


On Wed, Jan 11, 2017 at 7:08 AM David Sweeris <davesweeris at mac.com> wrote:

>
> On Jan 11, 2017, at 08:48, Derrick Ho via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Interesting proposal Tim. So instead of repeating the enum cases multiple
> times we repeat the functions multiple times?
>
> I feel like this merely flipping the complexity but not really getting rid
> of it.
>
>
> I *think* you have correctly summarized the proposal.
>
> 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.
>
> So... I guess I'm +1, pending someone who knows more about compiler
> internals weighing in on implementation implications.
>
> - Dave Sweeris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170111/0c3651d3/attachment.html>