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

[Paul Ossenbruggen]

Having it be compact was a goal, especially when doing simple mappings. Some of the feedback has been that conciseness is very important. However if means that the proposal won’t be accepted because of it then I will drop it. 

The thing is when you are just mapping expressions the repetition of the case is often bigger than what you are mapping. Also, case is necessary when you have multiple lines to get a result or when there is more complex pattern matching. With expressions there can only be one line each. 

	let v = match(3) { cases 1:  “A”, 2: “B”, 3: “C”, default: “D” }

or even when fully specified in the cases for example:

	let v = match(3) { cases 1: “A”, 2: “B”, 3: “C”, _: “D” }

is much simpler and I would say easier to read than

	let v = match(3) { case 1: “A”, case 2: “B”, case 3: “C”, default: “D” }

Some will say that you are trying to do too much on one line but it may just be a situation that you don’t want the weight of a multiline statement. 

I don’t think that the cases syntax is any harder than reading a dictionary with multiple key values on one line. Especially when syntax coloring ion. 

For multi line mappings it can also help.

	let s = match(3) { cases
		1: “here is a long sentence that fills the line”,
		2: “another sentence that fills the line”,
		3: “a final sentence that fills the line”,
		_: “default sentence that fills the line"
	}

the repeated word “case" in this situation does not add anything or make it any clearer. It can be used like a dictionary with a default, with the advantage that it does an exhaustiveness test.

- Paul

> On Feb 4, 2016, at 6:36 AM, Craig Cruden via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto: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>
> 
> _______________________________________________
> 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/20160204/c467fad8/attachment.html>