<html><body><div>You are right, it seems that Scala is doing automatic unsplatting now. Why it doesn't work for reduce I can't say.<br></div><div><br data-mce-bogus="1"></div><div>-Thorsten<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br>Am 05. Februar 2016 um 07:01 schrieb Craig Cruden &lt;ccruden@novafore.com&gt;:<br><br><div><blockquote type="cite"><div class="msg-quote" style="word-wrap: break-word;" data-mce-style="word-wrap: break-word;">No, that cannot be the reason.<div class=""><br class=""></div><div class="">— this works</div><div class=""><div class="">val r2 = a.foldLeft(0) &nbsp;{</div><div class="">&nbsp; case (acc, x) if x &gt; 4 =&gt; println(x); acc + x</div><div class="">&nbsp; case (acc, x) if x &lt;= 4 =&gt; acc - x</div><div class="">}</div><div class=""><br class=""></div><div class="">— this does not.</div><div class="">val r3 = a.reduce {</div><div class="">&nbsp; case (acc, x) if x &gt; 4 =&gt; println(x); acc + x</div><div class="">&nbsp; case (acc, x) if x &lt;= 4 =&gt; acc - x</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 2016-02-05, at 12:59:06, Thorsten Seitz &lt;<a href="mailto:tseitz42@icloud.com" class="" data-mce-href="mailto:tseitz42@icloud.com">tseitz42@icloud.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class=""><br></div><div class="">The reason is simply that partial functions in Scala are unary function, i.e. take only one argument, while reduce takes a binary function.</div><div class=""><br class=""></div><div class="">I already wrote in another mail why I think that the reduce example in the proposal is problematic, because it does argument splatting.</div><div class=""><br class=""></div><div class="">-Thorsten&nbsp;</div><div class=""><br class="">Am 04.02.2016 um 22:57 schrieb Craig Cruden via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Off Topic a little.</div><div class=""><br class=""></div>I was playing around with the equivalent case - partial functions in Scala ….&nbsp;<div class=""><br class=""></div><div class="">I have known for whatever reason that they would not work within the Scala `reduce` but would work in other functions…. &nbsp;and it bugged me as to why it would work in most but not all (I was wondering if this was some weird implementation limitation). &nbsp;</div><div class=""><br class=""></div><div class="">As far as I can tell, there is a little difference that prevents it. &nbsp;Swift reduce is probably the same as Scala’s foldLeft. &nbsp;I had thought Scala’s reduce is a specialized form of fold but it is not the case.</div><div class=""><br class=""></div><div class="">The difference has to be that Scala’s `reduce` takes a “commutative monoid” — and case partial functions by their very nature [conditions on accumulator or value prevent it] are not commutative in nature — or at least not guaranteed to be so. &nbsp;</div><div class=""><br class=""></div><div class="">Scala’s fold is either left to right, or right to left. &nbsp;`reduce` on the other hand provides no guarantees because it may parallelize it [I am wondering if this is something in common with the concept of big data mapReduce].</div><div class=""><br class=""></div><div class="">——</div><div class=""><br class=""></div><div class="">Paul, I will look at updating the proposal to make that clear.&nbsp;</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">On 2016-02-05, at 4:17:03, Paul Ossenbruggen via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">I haven't thought of doing it this way This is why these reviews are great. I agree with Craig that, we would not allow commas before the colon. The proposal probably should be updated to make sure that is clear.&nbsp;</div><div class=""><br class="">Thanks&nbsp;</div><div class="">- Paul&nbsp;</div><div class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Feb 4, 2016, at 10:31 AM, Maximilian Hünenberger &lt;<a href="mailto:m.huenenberger@me.com" class="" data-mce-href="mailto:m.huenenberger@me.com">m.huenenberger@me.com</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">I definitely see the point against dictionaries but I’m afraid of the actual pattern matching in "cases".</div><div class=""><br class=""></div><div class="">match(1) {</div><div class="">&nbsp; &nbsp; case 1, 3: 10</div><div class="">&nbsp; &nbsp; case 2, 4: 20</div><div class="">&nbsp; &nbsp; default: 30</div><div class="">}</div><div class=""><br class=""></div><div class="">// with "cases"</div><div class=""><br class=""></div><div class=""><div class="">match(1) { cases</div><div class="">&nbsp; &nbsp; 1, 3: 10,</div><div class="">&nbsp; &nbsp; 2, 4: 20,</div><div class="">&nbsp; &nbsp; default: 30</div><div class="">}</div></div><div class=""><br class=""></div><div class="">// it is very hard to disambiguate between pattern and return value even though for the compiler it could be doable</div><div class=""><div class="">match(1) { cases</div><div class="">&nbsp; &nbsp; 1, 3: 10, 2, 4: 20, default: 30</div><div class="">}</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">There should be a more visible distinction between two "<span style="color: #333333; background-color: #ffffff;" class="" data-mce-style="color: #333333; background-color: #ffffff;">case-item-map" <b class=""><u class="">like</u></b> "|". But we have to consider "expression-patterns" where operators (like "|") are ambiguous.</span></div><div class=""><span style="color: #333333; background-color: #ffffff;" class="" data-mce-style="color: #333333; background-color: #ffffff;"><br class=""></span></div><div class=""><span style="background-color: #ffffff;" class="" data-mce-style="background-color: #ffffff;"><span style="color: #333333;" data-mce-style="color: #333333;" color="#333333">-&nbsp;Maximilian</span></span></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Am 04.02.2016 um 18:48 schrieb Paul Ossenbruggen &lt;<a href="mailto:possen@gmail.com" class="" data-mce-href="mailto:possen@gmail.com">possen@gmail.com</a>&gt;:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">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. &nbsp;<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On Feb 4, 2016, at 8:38 AM, Charles Constant via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">I still vote for keeping "cases"</div><br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><div class="">I see it as a replacement for dictionary literal "pattern matching":<br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'menlo'; color: #d12f1b;" class="" data-mce-style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'menlo'; color: #d12f1b;"><span class="">[</span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">1</span><span class=""> : </span>"one"<span class="">, </span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">2</span><span class=""> : </span>"two"<span class="">, </span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">3</span><span class=""> : </span>"three"<span class="">][</span><span style="color: #272ad8;" class="" data-mce-style="color: #272ad8;">1</span><span class="">] ?? </span>"undefined"</div></div><div class=""><br></div></div></blockquote><div class=""><br class=""></div><div class="">A dictionary needs keys that are Hashable. A dictionary produces an optional. We've discussed this, and more, earlier in the thread.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><div class="">Even though it would be nice to have but I don’t think that I would use it frequently.</div></div></blockquote><div class=""><br class=""></div><div class="">Granted, it's a bit ugly, but given the choice, I would pick "cases" over "case case case case ..." every time.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;" data-mce-style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: #cccccc; border-left-style: solid; padding-left: 1ex;"><div style="word-wrap: break-word;" class="" data-mce-style="word-wrap: break-word;"><div class="">In addition, to be more consistent with "case", "cases" would introduce pattern matching which doesn’t seem right with this concise syntax.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="" data-mce-href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="" data-mce-href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></body></html>