[swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Matthew Johnson]

> On Feb 28, 2017, at 10:39 AM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Having watched this conversation from the sidelines, I just wanted to chime in from a more distant view:
>> 
>> Originally, I thought this proposal was very nice because it made a good argument as to why enum cases would benefit from being function-like. It follows naturally that form should follow function, and therefore it's hard to argue that the syntax shouldn't be "rectified."
>> 
>> But, given the latest discussions, it seems that there's a bunch of round-peg-square-hole efforts going on precisely because enum cases *aren't* very function-like in some key respects:
>> 
>> - John McCall gives a cogent reason why parameter names and argument labels would be inconsistently used if they are put to the purpose that some have proposed here for enum cases.
>> 
>> - There's a lot of bikeshedding as to pattern matching with argument labels, as it seems that people generally agree that always requiring them in that scenario would make the experience of using enums worse rather than better. In fact, it seems that what's cited as a shortcoming in the original proposal ("labels in patterns aren't enforced") is precisely what we're trying to invent new sugar to duplicate.
>> 
>> Now, since we clearly want enum cases to be tuple-like in some respects (pattern matching) but function-like in other respects, is swinging from one extreme ("cases are tuples!") to the other ("cases are functions!") the right thing to do? Does it really make the language more "consistent"?
> 
> It would absolutely make the implementation more consistent, since cases in expressions are the last vestige keeping a lot of damaged code in the type-checker alive to deal with argument label/tuple label ambiguity. Personally, I don't think that requiring labels in pattern matching is an undue burden, and I agree it's not a good idea to try to make up sugar to "un-require" them:
> 
> - It's totally self-imposed verbosity—nobody *has* to label their case payloads, and if you feel compelled to, it must be for a good reason. In my mind, those reasons shouldn't come up that often in practice, since enums with compound payloads are often better factored into a combination of enums and structs, and single-element payloads are best left unlabeled, like `some` or `string`/`number`/`array`/`object`.

I agree with you about factoring out compound payloads.  If we could pattern match structs as well as declare and use a `case struct` with lightweight syntax I’m not sure I would use compound cases at all anymore.

> - In general, pattern-matching syntax ought to behave as a mirror image of the expression that constructs a matching value, with holes punched into it via '_' or 'let' subpatterns. A lot of people already struggle with the concept, and unnecessary divergence from the behavior of expressions is added complexity. We already have too many inconsistencies in this area (implicit conversions in expressions don't fire in patterns; some pattern forms are artificially hardcoded to only look up enum cases; there are weird and technically redundant forms like "is T") that make learning patterns difficult.

This is a fair point.

> 
> -Joe