<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.&nbsp;<div class=""><br class=""></div><div class="">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.&nbsp;<div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>let v = match(3) { cases 1: &nbsp;“A”, 2: “B”, 3: “C”, default: “D” }</div><div class=""><br class=""></div><div class="">or even when fully specified in the cases for example:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>let v =&nbsp;match(3) { cases 1: “A”, 2: “B”, 3: “C”, _: “D” }</div></div><div class=""><br class=""></div><div class="">is much simpler and I would say easier to read than</div><div class=""><br class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>let v =&nbsp;match(3) { case 1: “A”, case 2: “B”, case 3: “C”, default: “D” }</div></div><div class=""><br class=""></div><div class="">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.&nbsp;</div><div class=""><br class=""></div><div class="">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.&nbsp;</div><div class=""><br class=""></div><div class="">For multi line mappings it can also help.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>let s =&nbsp;match(3) { cases</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>1: “here is a long sentence that fills the line”,</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>2: “another sentence that fills the line”,</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>3: “a final sentence that fills the line”,</div><div class=""><span class="Apple-tab-span" style="white-space:pre">                </span>_: “default sentence that fills the line"</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">- Paul</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 4, 2016, at 6:36 AM, Craig Cruden via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Can we have a vote on removing / keeping the cases clause. &nbsp;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).<div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-04, at 21:30:48, Thorsten Seitz &lt;<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="">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). <br class=""></div><div class=""><br data-mce-bogus="1" class=""></div><div class="">-Thorsten<br data-mce-bogus="1" class=""></div><div class=""><br data-mce-bogus="1" class=""></div><div class=""><br class="">Am 04. Februar 2016 um 15:18 schrieb Craig Cruden via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="msg-quote"><div class="_stretch"><span class="body-text-content">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.<br class=""><br class="">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…. <br class=""><br class=""><br class=""><blockquote type="cite" class="quoted-plain-text">On 2016-02-04, at 21:14:58, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>&gt; wrote:</blockquote><blockquote type="cite" class="quoted-plain-text"><br class=""></blockquote><blockquote type="cite" class="quoted-plain-text">Should we allow mixing "case" and "cases"?</blockquote><blockquote type="cite" class="quoted-plain-text"><br class=""></blockquote><blockquote type="cite" class="quoted-plain-text">I don't think so since a "cases" between several "case"'s is not recognizable enough.</blockquote><blockquote type="cite" class="quoted-plain-text"><br class=""></blockquote><blockquote type="cite" class="quoted-plain-text">With the current grammar "cases" is also allowed after "case" labels:</blockquote><blockquote type="cite" class="quoted-plain-text"><br class=""></blockquote><blockquote type="cite" class="quoted-plain-text">Example (this is currently allowed):</blockquote><blockquote type="cite" class="quoted-plain-text"><br class=""></blockquote><blockquote type="cite" class="quoted-plain-text">match(3) {</blockquote><blockquote type="cite" class="quoted-plain-text">case 1: "one"</blockquote><blockquote type="cite" class="quoted-plain-text">case 2: "two"</blockquote><blockquote type="cite" class="quoted-plain-text">cases 3: "three", 4: "four"</blockquote><blockquote type="cite" class="quoted-plain-text">default: "undefined"</blockquote><blockquote type="cite" class="quoted-plain-text">}</blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" data-mce-href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></span></div></div></blockquote></div></div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>