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

Craig Cruden ccruden at novafore.com
Thu Feb 4 08:36:28 CST 2016


Can we have a vote on removing / keeping the cases clause.  I personally would not typically use it, but there was a split on whether to keep it or delete it so I just kept it in the original until — as I expected — it would be dropped during review (assuming it has a chance of passing).

I though, do not find cases to be particularly hard to read if you have 10 key/value pairs over two lines…. and no mixture….. readability is of the sample in the document is concise in that example and quite readable for me (but I would probably still not use it).


> On 2016-02-04, at 21:30:48, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
> I already stated that I'm opposed to "cases" by themselves (too unreadably IMO because the keys and values are not sufficiently separated visually) so it should be no surprise that I'm similarly opposed to mixing "case" and "cases" (too confusing IMO). 
> 
> -Thorsten
> 
> 
> Am 04. Februar 2016 um 15:18 schrieb Craig Cruden via swift-evolution <swift-evolution at swift.org>:
> 
>> I originally had them mutually exclusive but there was pushback and the fact that no harm would be done by mixing them - I did not see the reason why not to allow them.
>> 
>> You could have a couple cases each with several lines of code then a value, and then a few that are just key/value mappings…. 
>> 
>> 
>>> On 2016-02-04, at 21:14:58, Maximilian Hünenberger <m.huenenberger at me.com> wrote:
>>> 
>>> Should we allow mixing "case" and "cases"?
>>> 
>>> I don't think so since a "cases" between several "case"'s is not recognizable enough.
>>> 
>>> With the current grammar "cases" is also allowed after "case" labels:
>>> 
>>> Example (this is currently allowed):
>>> 
>>> match(3) {
>>> case 1: "one"
>>> case 2: "two"
>>> cases 3: "three", 4: "four"
>>> default: "undefined"
>>> }
>> 
>> _______________________________________________
>> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160204/07b33fe6/attachment.html>


More information about the swift-evolution mailing list