> On Oct 26, 2016, at 2:32 AM, Adrian Kashivskyy via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
