[swift-evolution] Proposal: Pattern Matching Partial Function (#111)

Maximilian Hünenberger m.huenenberger at me.com
Thu Feb 4 12:45:46 CST 2016


To what extend should pattern matching be used in "cases"?

Can there be value bindings? The current grammar says "pattern" which means:
pattern → wildcard-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/wildcard-pattern>­type-annotation <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type-annotation>­opt­
 <>pattern → identifier-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/identifier-pattern>­type-annotation <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type-annotation>­opt­
 <>pattern → value-binding-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/value-binding-pattern>­
 <>pattern → tuple-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/tuple-pattern>­type-annotation <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Types.html#//apple_ref/swift/grammar/type-annotation>­opt­
 <>pattern → enum-case-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/enum-case-pattern>­
 <>pattern → optional-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/optional-pattern>­
 <>pattern → type-casting-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/type-casting-pattern>­
 <>pattern → expression-pattern <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Patterns.html#//apple_ref/swift/grammar/expression-pattern>­
 <>
> Am 04.02.2016 um 19:35 schrieb Craig Cruden <ccruden at novafore.com>:
> 
> cases was added instead of using `cases` because of the potential problems foreseen where the parser would have trouble identifying a list of values.  
> 
> cases would be restricted to key: value, key: value, key: value and would be considered syntactic sugar that would expand out to 
>     case key1: value1
>     case key2: value2
>     case key3: value3 
> as far as the compilation was concerned.
> 
> 
>> On 2016-02-05, at 1:31:09, Maximilian Hünenberger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".
>> 
>> match(1) {
>>     case 1, 3: 10
>>     case 2, 4: 20
>>     default: 30
>> }
>> 
>> // with "cases"
>> 
>> match(1) { cases
>>     1, 3: 10,
>>     2, 4: 20,
>>     default: 30
>> }
>> 
>> // it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable
>> match(1) { cases
>>     1, 3: 10, 2, 4: 20, default: 30
>> }
>> 
>> 
>> There should be a more visible distinction between two "case-item-map" like "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.
>> 
>> - Maximilian
>> 
>>> Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen <possen at gmail.com <mailto:possen at gmail.com>>:
>>> 
>>> That is a good point and I forgot about that. There are frequent cases where what I am dealing with is not hashable and it is generally a lot of work to make it hashable, including adding a heading function which if done wrong, can lead to errors.  
>>> 
>>> Sent from my iPhone
>>> 
>>> On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> I still vote for keeping "cases"
>>>> 
>>>> I see it as a replacement for dictionary literal "pattern matching":
>>>> [1 : "one", 2 : "two", 3 : "three"][1] ?? "undefined"
>>>> 
>>>> A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.
>>>> 
>>>> Even though it would be nice to have but I don’t think that I would use it frequently.
>>>> 
>>>> Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.
>>>> 
>>>> In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.
>>>> 
>>>> I haven't thought this through. It just bums me out a little to replace the switch with something that still has imho unnecessary verbosity.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160204/c01c2b18/attachment.html>


More information about the swift-evolution mailing list