[swift-evolution] [pitch] replace (if/guard) case = with ~=

Xiaodi Wu xiaodi.wu at gmail.com
Mon Oct 3 21:42:32 CDT 2016


On Mon, Oct 3, 2016 at 9:31 PM, Nevin Brackett-Rozinsky via swift-evolution
<swift-evolution at swift.org> wrote:

> While we’re on the subject, has there been any discussion about adding a
> pattern matching operator with the polarity reversed?
>
> To me at least it seems far more natural to write, eg., “case x =~
> somePattern” and to read it as “x matches somePattern” rather than the
> status quo “somePattern matches x”.
>

There has. My memory is foggy now, but I do believe this was one of those
things about which the core team chimed in to say that they had once
seriously considered or even implemented it and then backed it out.


Nevin
>
>
>
> On Mon, Oct 3, 2016 at 9:31 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> *Resolved*: `if case 1...10 = myNumber { ... }` is an abomination.
>>
>> It confuses inexperience developers. At least those few who are
>> aware of its existence. Using the assignment operator for pattern
>> matching adds insult to injury.
>>
>> I far prefer
>>     `if case .failure(let error) ~= result { ... } `
>> to
>>     `if case .failure(let error) = result {...}`
>>
>> Though worthy, this isn't a popular pattern.  A highly unscientific
>> survey of
>> gist reveal:
>>
>> * Gists using "if case": 94
>> * Gists that could use "if let" instead of "if case": Approximately 94-ish
>> * Gists using "guard case" (with significant overlap with "if case"): 54
>> * Gists that could use "guard let" or "guard x != nil" or "guard x ==
>> .enumeration" instead: About 54-ish
>> * Standard library: 1 use of "guard case", 5 uses of "if case".
>>
>> *Note*:
>>
>> * I love `guard case`/`if case` for `Result` enumerations
>> * I  love`for case let x? in [optionals]`.
>>
>> I don't expect changing `=` to `~=` would make a huge difference in
>> adoption
>> but it would satisfy  my inner code critic. Changing it would be breaking
>> but as far as I can tell, it wouldn't really break *that* *much* *code*
>>
>> -- E
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161003/513664c1/attachment.html>


More information about the swift-evolution mailing list