[swift-evolution] [Pitch] Reimagining guard case/if case

[Erica Sadun]

> On Oct 26, 2016, at 2:32 AM, Adrian Kashivskyy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I’m -1 as it’s currently written, for the following reasons:
> 
> 1. Differences are introduced to pattern matching in different parts of the language (`switch` vs `if`/`guard` vs `for`).

Pattern matching in Swift includes:

`switch case` and `for case`: The argument is pulled in indirectly:
    `switch value....case pattern:` and `for case pattern in sequence of values`

`guard case` and `if case`: The argument is expressed with an equal sign:
   `guard case pattern = value` and `if case pattern = value`

Operator use, excluding conditional binding: `pattern ~= value`.

I argue that the second group is closer to the third than the first because the value must be provided to the statement for `guard case`, `if case`, and the ~= operator.


> 2. Exclusion of `for` in the proposal is either deliberate (which relates to point 1.) or done as a result of a rush, which is not good either. This proposal should include a resolution for `for case let where` clauses.

Both `if case` and `guard case` don't use implied arguments, making them fundamentally a different type of check. If you insist that the keyword "case" be used for pattern matching, then under your argument it should appear in other parts of the language where pattern matching occurs. 

Since it doesn't, and you can check membership in a range with "range ~= value", why shouldn't the grammar for these two items be moved from the "passive implied arguments" group to the "explicit arguments" group, given that they use explicit arguments?

> 3. Syntatic sugar of optional matching `let x? ~= maybeX` feels completely out of place and looks nothing like standard optional bindings. I will remain strongly against this change.

I'd suggest that's a subjective issue with the sugar, not with the use of ~=. 

-- E