> On Feb 28, 2017, at 10:39 AM, Joe Groff <[email protected]> wrote: > > >> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
