<div dir="ltr">On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Jun 26, 2016, at 10:35 AM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt; wrote:</div><br><div><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">on Sat Jun 25 2016, Erica Sadun &lt;</span><a href="http://erica-at-ericasadun.com/" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">erica-AT-ericasadun.com</a><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">&gt; wrote:</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Jun 25, 2016, at 4:25 PM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>&gt; wrote:<br><blockquote type="cite">on Wed Jun 22 2016, Erica Sadun &lt;<a href="http://erica-at-ericasadun.com" target="_blank">erica-AT-ericasadun.com</a>&gt; wrote:<br>On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote type="cite"><br>-    func forEach&lt;S: SequenceType&gt;(_ body: (S.Iterator.Element) -&gt; ())<br>+    func forEach&lt;S: SequenceType&gt;(invoke body: (S.Iterator.Element) -&gt; ())<br><br>Adding an external label makes sense here. This is a procedural call and<br>using it within the parens should have a &quot;code ripple&quot;.<br></blockquote><br>I don&#39;t think I understand what you mean here.<br></blockquote><br>When using a procedural &quot;trailable&quot; closure inside parentheses, the intention<br>to do so should be clear:<br><br>p(x, perform: {...})<br>p(x, do: {...})<br><br>vs<br><br>p(x) {<br>  ...<br>}<br><br>Anyone reading this code can immediately identify that an otherwise trailing<br>closure has been pulled inside the signature because the call has become<span> </span><br>significantly more  complex. The point-of-coding decision ripples through<br>to point-of-reading/point-of-maintenance.<br><br><blockquote type="cite"><blockquote type="cite">That said, would prefer `do` or `perform` over `invoke` or `invoking` as in<br>`runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc.<span> </span><br></blockquote><br>Sorry, again, I&#39;m a little lost.  Forgive my overly-literal brain but<br>could you please spell out how those latter 3 names relate to the choice<br>of `do` or `perform` over `invoke`?   <br></blockquote><br>I read through the pull request. I grouped related modifications<br>together, although not exhaustively. They fall under the same umbrella,<span> </span><br>choosing `do` or `perform` compared to `invoke` or `invoking`.<br><br>-    _forAllPermutationsImpl(index + 1, size, &amp;perm, &amp;visited, body)<br>+    _forAllPermutationsImpl(index + 1, size, &amp;perm, &amp;visited, invoke: body)<br><br>-public func runRaceTest(trials: Int, threads: Int? = nil, body: () -&gt; ()) {<br>+public func runRaceTest(<br>+  trials: Int, threads: Int? = nil, invoking body: () -&gt; ()<br>+) {<br><br>-public func expectFailure(${TRACE}, body: () -&gt; Void) {<br>+public func expectFailure(${TRACE}, invoking body: () -&gt; Void) {<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">OK, I understand your process now.  I still don&#39;t understand your</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">rationale for saying `do` or `perform` is better than `invoke`.  Or is</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">it just personal taste?</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></div></div><div>See below.  But in a  nutshell, `do` gets the idea across. It&#39;s short. It&#39;s pithy.</div><div>It uses a common, comfortable word. So yes, personal taste. But it&#39;s personal</div><div>taste backed up by some statistics.</div></div></div></blockquote><div><br></div><div>I&#39;ve made this comment previously in another thread, but I&#39;ll chime in here because it seems pertinent. Just like the parentheses around function arguments can imply the word &quot;with&quot; or &quot;using,&quot; and just as Swift 3 renamed `foo(atIndex: Int)` to `foo(at: Int)` because an argument of type Int implies an index, a closure to me implies the word &quot;do,&quot; &quot;invoke,&quot; &quot;perform&quot; or even &quot;soEach.&quot; After all, it&#39;s absurd that a closure would be supplied as an argument for any purpose other than being done or invoked or performed. That a label such as `do` or `body` or `soEach` could be applied so broadly seems to me a good sign that these labels might be extraneous.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">This also applies where there&#39;s a `body` label instead of an empty<br>external label.<br></blockquote><br>We don&#39;t have any methods with a `body` label IIUC.<br></blockquote><br>You did, as in the examples just above, which you recommend a rename to `invoke` or<br>`invoking`.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Ah, thanks.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">-public func withInvalidOrderings(_ body: ((Int, Int) -&gt; Bool) -&gt; Void) {<br>+public func withInvalidOrderings(invoke body: ((Int, Int) -&gt; Bool) -&gt; Void) {<br><br>For any with/external label pair, I&#39;d prefer `with-do` or `with-perform`<span> </span><br>over `with-invoke`.<br></blockquote><br>OK.  Is there a rationale, or is it just personal taste?<br></blockquote><br>Strong personal taste, backed by tech writing. Simpler words.<span> </span><br>From the Corpus of Contemporary American English:<br>do: 18<br>perform: 955<br>invoke: does not appear on list.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I&#39;m unable to reproduce those numbers using<span> </span></span><a href="http://corpus.byu.edu/coca/" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://corpus.byu.edu/coca/</a><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">What exactly did you do to get them?</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>I used a secondary webpage that rates word frequency based on the COCA corpus:</div><div><a href="http://www.wordfrequency.info/free.asp?s=y" target="_blank">http://www.wordfrequency.info/free.asp?s=y</a></div><span class=""><div><br></div><br><blockquote type="cite"><div><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Also, I&#39;m not sure commonality of use is a good rationale.  I bet</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">“function” doesn&#39;t appear as often as “task” either, but the argument</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">here is a function and we invoke functions.  Sometimes the appropriate</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">word is just less common.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>1051 task</div><div>1449 function</div><div><br></div><div>Numbers aside, there&#39;s always a &quot;term of art&quot; argument to be made. A term of</div><div>art is precise and instantly communicates the meaning to the user. </div><div><br></div><div>I don&#39;t think a &quot;term of art&quot; argument can be made here since invoke, perform, and </div><div>do all communicate the same idea to the end-coder, who doesn&#39;t need to know </div><div>exactly how the compiler sees the argument.</div><div><br></div><div>In naming theory, I&#39;d say the member name carries the greatest weight when using</div><div>exact terms and that internal labels should accessorize the primary name. When using a</div><div>&quot;term of art&quot; argument, it should apply most strongly to a method/function/</div><div>property/type name and less to supporting external labels.</div><span class=""><div><br></div><blockquote type="cite"><div><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">-  return IteratorSequence(it).reduce(initial, combine: f)<br>+  return IteratorSequence(it).reduce(initial, accumulatingBy: f)<br><br>For `reduce`, I&#39;d prefer `applying:` or `byApplying:`<br></blockquote><br>Makes sense.<br><br><blockquote type="cite">Similarly in `starts(with:comparingBy:)`, I&#39;d prefer byComparing`,<br></blockquote><br>I don&#39;t see how that works.  You&#39;re not comparing the closure with<br>anything.<br></blockquote><br>I get your point but I think it&#39;s unnecessarily fussy.<span> </span><br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I plead guilty to sometimes having unnecessarily fussy tendencies, but</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">in this case I believe strongly that “byComparing” would be actively</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">misleading and harmful.  Even if there&#39;s only one possible sane</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">interpretation, if readers have to scratch their heads and do an</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">exhaustive search through possible interpretations of what something</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">might mean because the one directly implied by the grammar is nonsense,</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">that&#39;s bad.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>&quot;Comparing by&quot; is not actively misleading or harmful but it does sound</div><div>strained.  I think a well-designed language should use comfortable</div><div>constructs.Why not use a single , plain word that describes a parameter&#39;s</div><div>role. Why not &quot;compare:&quot;? It&#39;s far less fussy and it&#39;s clear.</div><span class=""><br><blockquote type="cite"><div><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Alternatives are slim on the ground. `usingComparison:` is too long,<br>as is `byComparingWith:` (which still reads better but you will point<br>out can be mistaken by some pedant to mean that the sequence is being<br>compared to the closure), and you won&#39;t allow for `comparing:`.  I&#39;m<br>not in love with `comparingWith:` but it reads slightly better to me<br>than `comparingBy:`.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">There is definitely something awkward about “xxxBy:” for these uses, and</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I&#39;m open to using “xxxWith:” instead, even though as you say it&#39;s</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">confusable.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> if x.starts(with: y, comparingBy: { $<a href="http://0.name" target="_blank">0.name</a> == $<a href="http://1.name" target="_blank">1.name</a> }) {</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">   ...</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> }</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> if x.starts(with: y, comparingWith: { $<a href="http://0.name" target="_blank">0.name</a> == $<a href="http://1.name" target="_blank">1.name</a> }) {</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">   ...</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> }</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">At some point I start to wonder if giving up fluency is best:</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> if x.starts(with: y, equality: { $<a href="http://0.name" target="_blank">0.name</a> == $<a href="http://1.name" target="_blank">1.name</a> }) {</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">   ...</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"> }</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>Yes.  `predicate`, `compare` (or `comparison`), `order:`, etc.</div><div><br></div><div>To riff off Gerard Manley Hopkins, &quot;Glory be for simple things, for</div><div>short words and trim APIs&quot;.</div></div><div><br></div><div><span class=""><blockquote type="cite"><div><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">min/max, byOrdering<br></blockquote><br>Likewise, you&#39;re not ordering the closure.<br></blockquote><br>Same reasoning.<br><br><blockquote type="cite"><br><blockquote type="cite">-      ).encode(encoding, output: output)<br>+      ).encode(encoding, sendingOutputTo: processCodeUnit)<br><br>How about `exportingTo`?<br></blockquote><br>“export” is freighted with various connotations that I don&#39;t think we<br>want to make here.  In fact it doesn&#39;t mean anything more exotic than<br>“sending output to.”<br></blockquote><br>For a language that treasures concision and clarity, this may be clear<br>but it&#39;s notably inconcise. (Yes, that is a new word.)<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I agree, but if you want concision I&#39;d rather stick with something that</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">doesn&#39;t imply anything unintended, such as “to” or “into.”</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span>I much prefer `to` and `into`</div><div><span class=""><br><blockquote type="cite"><div><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">-  tempwords.sort(isOrderedBefore: &lt;)<br>+  tempwords.sort(orderingBy: &lt;)<br><br>With `sort` and `sorted`, I&#39;d prefer `by:`<br></blockquote><br>When people talk about “sorting by XXX”, XXX is a property of the<br>elements being sorted.  Therefore IMIO that label should probably be<br>reserved for a version that takes a unary projection function:<br><br>   friends.sort(by: {$0.lastName})<br></blockquote><br>But they&#39;re sorting now, and that feature isn&#39;t in Swift.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">That doesn&#39;t mean we should claim the syntax for another purpose.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I think we probably do want that feature eventually.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">However, `sorted` falls under another umbrella, which is potential<br>chaining. In such case, I would prefer there be no internal label at all<br>to allow cleaner functional flow.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">IMO whether a method has a non-Void return value (and thus is chainable)</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">should not be the determining feature on whether we use argument labels.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>If any method returns a sequence or collection, I think it *should* be considered</div><div>in that specific light as a candidate for chaining. I agree that expanding that to</div><div>any return value is too wide.</div><span class=""><br><blockquote type="cite"><div><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">We *could* decide to drop all labels for trailing closures (on the</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">grounds that they often won&#39;t appear at the call site) and say the</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">policy is that if there&#39;s something you want to communicate about the</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">closure&#39;s role, you simply do the best you can with the parameter name</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">and let the clarity at the call site fend for itself.  That, at least,</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">would be a reasonably principled approach.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></span><div>I like labels for trailing closures when they are  `-&gt; Void`.  You know a priori</div><div>that the closure is used for side-effects, so if they are put into a function or</div><div>method call, the label alerts you to design intent.</div><div><br></div><div>I want to omit labels for trailing closures when they return collections, sequences, </div><div>iterators, etc. because these return types are most likely to be chained.</div><div><br></div><div>If you force a label for, say, map, people will choose </div><div><br></div><div><font face="Menlo">map {  ...  }</font></div><div><br></div><div>over</div><div><br></div><div><font face="Menlo">map(label: { ... })</font></div><div><br></div><div>because the former reads better, especially when chaining but it introduces</div><div>bad habits, because it will not compile when used with constructs like:</div><div><br></div><div><font face="Menlo">for i in map { ... } { // will not compile<br>    ... </font></div><div><font face="Menlo">}</font></div><div><br></div><div>But if you treat collection/sequence fp as &quot;highly likely to be chained&quot;, it encourages</div><div>results more like:</div><div><br></div><div><font face="Menlo">for i in x.map({ ...}).filter({ ... }) {</font></div><div><font face="Menlo">    ....</font></div><div><font face="Menlo">}</font></div><div><br></div><div>which is compiler-safe, more readable, etc, especially for very short-form items like:</div><div><br></div><div><div><font face="Menlo">for var i in x.flatMap({Int($0)}).filter({ $0 &lt; 10 }) {</font></div><div><font face="Menlo">    ...</font></div><div><font face="Menlo">}</font></div></div><div><div class="h5"><div><br></div><div><br></div><blockquote type="cite"><div><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">-  if !expected.elementsEqual(actual, isEquivalent: sameValue) {<br>+  if !expected.elementsEqual(actual, comparingBy: sameValue) {<br><br>I&#39;m torn on this one. I don&#39;t like but I don&#39;t have a good solution.<br></blockquote></blockquote><br>I actually meant to move this up to the other discussion of `byComparing` and<br>forgot to. So please assume you disagree with me on this one too.<br><br><blockquote type="cite"><blockquote type="cite"><br>-  /// for which `predicate(x) == true`.<br>+  /// for which `isIncluded(x) == true`.<br>-      _base: base.makeIterator(), whereElementsSatisfy: _include)<br>+      _base: base.makeIterator(), suchThat: _include)<br><br>How about simply `include` for both?<span> </span><br></blockquote><br>Looking at the effect on the doc comments—which is how we should judge<br>parameter names—I think `predicate` might read better.<br></blockquote><br>I like `predicate`. I endorse `predicate`. Does this mean the rule of &quot;must<br>read like a sentence&quot; can be overturned for things like &quot;comparison&quot; and<br>&quot;order&quot;? If so, woo!<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I don&#39;t know what you mean.  There is no such rule.  There are</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">guidelines about reading like a phrase at the use site, but the</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">*parameter name* has no effect on the use site.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">I get the `is` desire but it&#39;s being tossed away in a lot of other<br>places in this diff. and `suchThat` feels out of place.<br></blockquote><br>I think I&#39;m pretty strongly sold on “soEach” as a label for closures in<br>all the filtering components.<br></blockquote><br>To quote greatness:, &quot;I personally find `soEach` repulsive&quot;.<br>(cite:<br><a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive" target="_blank">http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive</a><br>&lt;<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive" target="_blank">http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive</a>&gt;)<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Sorry to hear that.  Let&#39;s change “filter” to “where” so this can become</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">a non-issue.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></div></div><div>:)</div><div><div class="h5"><br><blockquote type="cite"><div><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><br><blockquote type="cite">-      || u16.contains({ $0 &gt; 127 || _isspace_clocale($0) }) {<br>+    || u16.contains(elementWhere: { $0 &gt; 127 || _isspace_clocale($0) }) {<br><br>I assume the challenge here is differentiating contains(element) from contains(closure).<br>This feels predicate-y, which is why I put it near the predicates. But I think something<br>like `containsElement(where:)` works better.<br></blockquote><br>I understand your motivation for suggesting it.  The downside is that it<br>severs the strong basename relationship between algorithms that do<br>effectively the same things, one using a default comparison and the<br>other using an explicitly-specified one.  I&#39;m truly not sure where we<br>ought to land on this one.<br></blockquote><br>May I recommend `predicate:` then since it looks like that&#39;s actually<br>a possibility?<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I never suggested predicate as an argument label.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><blockquote type="cite">-    let result = try base._withUnsafeMutableBufferPointerIfSupported(body)<br>+    let result = try base._withUnsafeMutableBufferPointerIfSupported(invoke: body)<br><br>I hate &quot;ifSupported&quot;<span> </span><br></blockquote><br>Me too.<br><br><blockquote type="cite">but that&#39;s another discussion<br></blockquote><br>Quite.  It&#39;s also an internal API so it&#39;s not an evolution issue.  The<br>point of having that change as part of the diff (as with all the other<br>use sites), is to observe how the changes affect real usage.<br></blockquote><br>Woody Allen: &quot;The heart wants what it wants&quot;<br>Me: &quot;The spleen vents what it vents&quot;<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">SOL (snort out loud)</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><br><blockquote type="cite">(withSupportedUnsafeMutableBufferPointer,<br>withAvailableUnsafeMutableBufferPointer, it&#39;s all lipstick)<br><br>This is procedural, so `do` or `perform` rather than `invoke`<br><br>-      for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {<br>+      for test in removeFirstTests.filter(<br>+        suchThat: { $0.numberToRemove == 1 }<br><br>The difference between `filter` and `forEach` is that `forEach` is explicitly<span> </span><br>procedural while `filter` is functional.  I do not like functional chainable<br>calls being modified to use explicit external labels in this way.<span> </span><br><br>I&#39;d prefer no label here.<br></blockquote><br>Can you provide rationale for treating functional methods differently,<br>or is it just personal taste?<br></blockquote><br>Functional programming flow. I follow Kevin Ballard&#39;s rule of parens around<br>functional elements and naked braces for trailing closures that do not return<br>values. This ensures the compiler is never confused at places like:<br><br>for x in foo when y.f{...} {<br>   ...<br>}<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">? It&#39;s never confused there; it tells you it&#39;s illegal.</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">and instantly identifies to the reader when there&#39;s a non-returning scope, as<br>in forEach or GCD dispatch.<br></blockquote><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Why is it useful to identify when there&#39;s a scope that doesn&#39;t return a</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">value?  Isn&#39;t that already clear from whether the value is assigned</span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">somewhere?  </span><br style="font-family:Palatino-Roman;font-size:14px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></blockquote><div><br></div></div></div>Enhanced readability from explicit coding intent. Trailing closures </div><div>*look* like a scope created by a native construct. Those enclosed in </div><div>parens *look* like arguments.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- E</div><div><br></div></font></span></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div></div>