<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 26 Jun 2016, at 02:03, Erica Sadun 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="">On Jun 25, 2016, at 4:25 PM, Dave Abrahams &lt;<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>&gt; wrote:<br class=""><div class=""><blockquote type="cite" class="">on Wed Jun 22 2016, Erica Sadun &lt;<a href="http://erica-at-ericasadun.com/" class="">erica-AT-ericasadun.com</a>&gt; wrote:<br class=""><div class=""><div class="">On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<blockquote type="cite" class="">- &nbsp;&nbsp;&nbsp;func forEach&lt;S: SequenceType&gt;(_ body: (S.Iterator.Element) -&gt; ())<br class="">+ &nbsp;&nbsp;&nbsp;func forEach&lt;S: SequenceType&gt;(invoke body: (S.Iterator.Element) -&gt; ())<br class=""><br class="">Adding an external label makes sense here. This is a procedural call and<br class="">using it within the parens should have a "code ripple".<br class=""></blockquote><br class="">I don't think I understand what you mean here.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">When using a procedural "trailable" closure inside parentheses, the intention</div><div class="">to do so should be clear:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">p(x, perform: {...})</font></div><div class=""><font face="Menlo" class="">p(x, do: {...})</font></div><div class=""><br class=""></div><div class="">vs</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">p(x) {</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp;...</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">Anyone reading this code can immediately identify that an otherwise trailing</div></div><div class="">closure has been pulled inside the signature because the call has become&nbsp;</div><div class="">significantly more &nbsp;complex. The point-of-coding decision ripples through</div><div class="">to point-of-reading/point-of-maintenance.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">That said, would prefer `do` or `perform` over `invoke` or `invoking` as in<br class="">`runRaceTest`, `_forAllPermutationsImpl`, `expectFailure`, etc. <br class=""></blockquote><br class="">Sorry, again, I'm a little lost. &nbsp;Forgive my overly-literal brain but<br class="">could you please spell out how those latter 3 names relate to the choice<br class="">of `do` or `perform` over `invoke`? &nbsp;&nbsp;<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I read through the pull request. I grouped related modifications</div><div class="">together, although not exhaustively. They fall under the same umbrella,&nbsp;</div><div class="">choosing `do` or `perform` compared to `invoke` or `invoking`.</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">- &nbsp; &nbsp;_forAllPermutationsImpl(index + 1, size, &amp;perm, &amp;visited, body)</font></div><div class=""><font face="Menlo" class="">+ &nbsp; &nbsp;_forAllPermutationsImpl(index + 1, size, &amp;perm, &amp;visited, <b class="">invoke</b>: body)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div></div><div class=""><div class=""><font face="Menlo" class="">-public func runRaceTest(trials: Int, threads: Int? = nil, <b class="">body</b>: () -&gt; ()) {</font></div><div class=""><font face="Menlo" class="">+public func runRaceTest(</font></div><div class=""><font face="Menlo" class="">+ &nbsp;trials: Int, threads: Int? = nil, <b class="">invoking</b> body: () -&gt; ()</font></div><div class=""><font face="Menlo" class="">+) {</font></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><div class=""><font face="Menlo" class="">-public func expectFailure(${TRACE}, <b class="">body</b>: () -&gt; Void) {</font></div><div class=""><font face="Menlo" class="">+public func expectFailure(${TRACE}, <b class="">invoking</b> body: () -&gt; Void) {</font></div><div class=""><br class=""></div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">This also applies where there's a `body` label instead of an empty<br class="">external label.<br class=""></blockquote><br class="">We don't have any methods with a `body` label IIUC.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">You did, as in the examples just above, which you recommend a rename to `invoke` or</div><div class="">`invoking`.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">-public func withInvalidOrderings(_ body: ((Int, Int) -&gt; Bool) -&gt; Void) {<br class="">+public func withInvalidOrderings(invoke body: ((Int, Int) -&gt; Bool) -&gt; Void) {<br class=""><br class="">For any with/external label pair, I'd prefer `with-do` or `with-perform` <br class="">over `with-invoke`.<br class=""></blockquote><br class="">OK. &nbsp;Is there a rationale, or is it just personal taste?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Strong personal taste, backed by tech writing. Simpler words.&nbsp;</div><div class="">From the Corpus of Contemporary American English:</div><div class=""><ul class=""><li class="">do: 18</li><li class="">perform: 955</li><li class="">invoke: does not appear on list.</li></ul></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- &nbsp;return IteratorSequence(it).reduce(initial, combine: f)<br class="">+ &nbsp;return IteratorSequence(it).reduce(initial, accumulatingBy: f)<br class=""><br class="">For `reduce`, I'd prefer `applying:` or `byApplying:`<br class=""></blockquote><br class="">Makes sense.</div></div></blockquote><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">Similarly in `starts(with:comparingBy:)`, I'd prefer byComparing`,<br class=""></blockquote><br class="">I don't see how that works. &nbsp;You're not comparing the closure with<br class="">anything.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I get your point but I think it's unnecessarily fussy.&nbsp;</div><div class=""><br class=""></div><div class="">Alternatives are slim on the ground. `usingComparison:` is too long,</div><div class="">as is `byComparingWith:` (which still reads better but you will point</div><div class="">out can be mistaken by some pedant to mean that the sequence is being</div><div class="">compared to the closure), and you won't allow for `comparing:`.</div><div class="">I'm not in love with `comparingWith:` but it reads slightly better to me&nbsp;</div><div class="">than `comparingBy:`.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">min/max, byOrdering<br class=""></blockquote><br class="">Likewise, you're not ordering the closure.<br class=""></div></div></blockquote><div class=""><br class=""></div>Same reasoning.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;).encode(encoding, output: output)<br class="">+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;).encode(encoding, sendingOutputTo: processCodeUnit)<br class=""><br class="">How about `exportingTo`?<br class=""></blockquote><br class="">“export” is freighted with various connotations that I don't think we<br class="">want to make here. &nbsp;In fact it doesn't mean anything more exotic than<br class="">“sending output to.”<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">For a language that treasures concision and clarity, this may be clear</div><div class="">but it's notably inconcise. (Yes, that is a new word.)</div></div></div></div></blockquote><div><br class=""></div>verbose</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- &nbsp;tempwords.sort(isOrderedBefore: &lt;)<br class="">+ &nbsp;tempwords.sort(orderingBy: &lt;)<br class=""><br class="">With `sort` and `sorted`, I'd prefer `by:`<br class=""></blockquote><br class="">When people talk about “sorting by XXX”, XXX is a property of the<br class="">elements being sorted. &nbsp;Therefore IMIO that label should probably be<br class="">reserved for a version that takes a unary projection function:<br class=""><br class=""> &nbsp;&nbsp;&nbsp;&nbsp;friends.sort(by: {$0.lastName})<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">But they're sorting now, and that feature isn't in Swift.</div><div class=""><br class=""></div><div class="">However, `sorted` falls under another umbrella, which is potential</div><div class="">chaining. In such case, I would prefer there be no internal label at all</div><div class="">to allow cleaner functional flow.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- &nbsp;if !expected.elementsEqual(actual, isEquivalent: sameValue) {<br class="">+ &nbsp;if !expected.elementsEqual(actual, comparingBy: sameValue) {<br class=""><br class="">I'm torn on this one. I don't like but I don't have a good solution.<br class=""></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">I actually meant to move this up to the other discussion of `byComparing` and</div><div class="">forgot to. So please assume you disagree with me on this one too.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class="">- &nbsp;/// for which `predicate(x) == true`.<br class="">+ &nbsp;/// for which `isIncluded(x) == true`.<br class="">- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_base: base.makeIterator(), whereElementsSatisfy: _include)<br class="">+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_base: base.makeIterator(), suchThat: _include)<br class=""><br class="">How about simply `include` for both? <br class=""></blockquote><br class="">Looking at the effect on the doc comments—which is how we should judge<br class="">parameter names—I think `predicate` might read better.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I like `predicate`. I endorse `predicate`. Does this mean the rule of "must</div><div class="">read like a sentence" can be overturned for things like "comparison" and</div><div class="">"order"? If so, woo!</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">I get the `is` desire but it's being tossed away in a lot of other<br class="">places in this diff. and `suchThat` feels out of place.<br class=""></blockquote><br class="">I think I'm pretty strongly sold on “soEach” as a label for closures in<br class="">all the filtering components.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">To quote greatness:, "I personally find `soEach` repulsive".</div><div class="">(cite:&nbsp;<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive</a>)</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|| u16.contains({ $0 &gt; 127 || _isspace_clocale($0) }) {<br class="">+ &nbsp;&nbsp;&nbsp;|| u16.contains(elementWhere: { $0 &gt; 127 || _isspace_clocale($0) }) {<br class=""><br class="">I assume the challenge here is differentiating contains(element) from contains(closure).<br class="">This feels predicate-y, which is why I put it near the predicates. But I think something<br class="">like `containsElement(where:)` works better.<br class=""></blockquote><br class="">I understand your motivation for suggesting it. &nbsp;The downside is that it<br class="">severs the strong basename relationship between algorithms that do<br class="">effectively the same things, one using a default comparison and the<br class="">other using an explicitly-specified one. &nbsp;I'm truly not sure where we<br class="">ought to land on this one.<br class=""></div></div></blockquote><div class=""><br class=""></div>May I recommend `predicate:` then since it looks like that's actually a possibility?</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> - &nbsp;&nbsp;&nbsp;let result = try base._withUnsafeMutableBufferPointerIfSupported(body)<br class="">+ &nbsp;&nbsp;&nbsp;let result = try base._withUnsafeMutableBufferPointerIfSupported(invoke: body)<br class=""><br class="">I hate "ifSupported" <br class=""></blockquote><br class="">Me too.<br class=""><br class=""><blockquote type="cite" class="">but that's another discussion<br class=""></blockquote><br class="">Quite. &nbsp;It's also an internal API so it's not an evolution issue. &nbsp;The<br class="">point of having that change as part of the diff (as with all the other<br class="">use sites), is to observe how the changes affect real usage.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Woody Allen: "The heart wants what it wants"</div><div class="">Me: "The spleen vents what it vents"</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">(withSupportedUnsafeMutableBufferPointer,<br class="">withAvailableUnsafeMutableBufferPointer, it's all lipstick)<br class=""><br class="">This is procedural, so `do` or `perform` rather than `invoke`<br class=""><br class="">- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {<br class="">+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for test in removeFirstTests.filter(<br class="">+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;suchThat: { $0.numberToRemove == 1 }<br class=""><br class="">The difference between `filter` and `forEach` is that `forEach` is explicitly <br class="">procedural while `filter` is functional. &nbsp;I do not like functional chainable<br class="">calls being modified to use explicit external labels in this way. <br class=""><br class="">I'd prefer no label here.<br class=""></blockquote><br class="">Can you provide rationale for treating functional methods differently,<br class="">or is it just personal taste?<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">Functional programming flow. I follow Kevin Ballard's rule of parens around</div><div class="">functional elements and naked braces for trailing closures that do not return</div><div class="">values. This ensures the compiler is never confused at places like:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">for x in foo when y.f{...} {</font></div><div class=""><font face="Menlo" class="">&nbsp; &nbsp; ...</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">and instantly identifies to the reader when there's a non-returning scope, as</div><div class="">in forEach or GCD dispatch.</div><div class=""><br class=""></div><div class="">However, if you use chaining and if the language insists on external label&nbsp;</div><div class="">preambles, which would not be seen when using the call with a trailing closure,</div><div class="">it becomes far less readable and encourages people &nbsp;to use trailing closures to&nbsp;</div><div class="">avoid the label, i.e. an attractive nuisance. Simple selectors encourage better fp:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">let x = myStream.f1({...}).f2({...})</font></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">public func split(<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;maxSplits: Int = Int.max,<br class=""> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;omittingEmptySubsequences: Bool = true,<br class="">- &nbsp;&nbsp;&nbsp;isSeparator: @noescape (Base.Iterator.Element) throws -&gt; Bool<br class="">+ &nbsp;&nbsp;&nbsp;separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws -&gt; Bool<br class=""><br class="">I'm torn on this one. It's not the worst ever but something more like where/at/when<br class="">makes more sense to me than<br class="">"separatedWhere/separatedAt/separatedWhen".<br class=""></blockquote><br class="">The biggest reason to keep “separate” in the name is the connection with<br class="">the semantics of the other `split` method, that takes a single element<br class="">that is tested for equality. &nbsp;I think this is very similar to the<br class="">`contains(elementWhere` vs `containsElement(where` discussion. &nbsp;If you<br class="">leave “separate” out of the name it fails to imply that those elements<br class="">for which the predicate returns true are not present in the result.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">`predicate` ftw.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;count: __manager._headerPointer.pointee.count)<br class=""><br class="">For the sake of Zippy the Pinhead, surely there has to be something better than `pointee`.<br class="">Like...`reference`?<br class=""></blockquote><br class="">It's not a reference; it's a value. &nbsp;But that, my friend, is an<br class="">*entirely* different discussion. Let's try to stick to the scope of the<br class="">proposal: names and labels for parameters of function type, OK?<br class=""></div></div></blockquote><div class=""><br class=""></div>It was humor. It was at the end. I assumed the joke would lighten the</div><div class="">previous complaints and bookend the positive support at the start of</div><div class="">my message.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">-Dave<br class=""></div></div></blockquote><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""></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 class="">The problem with finding a good argument label for “filter” is that when you use it as a verb in regular English, you typically mean to filter something _out_, but in this usage, we mean a specifier for the items to include.</div><div class=""><br class=""></div><div class="">If we flipped it (that’s another proposal, I know), we could have the eloquent-looking:</div><div class=""><br class=""></div><div class="">[1, 2, 3, 4, 5].filter(out: { $0 &gt; 3 }) &nbsp; // Returns [1, 2, 3]&nbsp;</div><div class=""><br class=""></div><div class="">Otherwise, the only context I can think of where you regularly talk about inclusive filters is in electronics, where we have low-pass/high-pass filters. Given that:</div><div class=""><br class=""></div><div class="">[1, 2, 3, 4, 5].filter(passing: { $0 % 2 == 0 }) &nbsp; // Returns [2, 4]&nbsp;</div><div class=""><br class=""></div><div class="">I’m not sure about it, but I definitely think it should be “passing” or “including” or some other very descriptive word that indicates the closure is a pass condition. “filter(where: {})” could be either an inclusive or exclusive filter.</div><div class=""><br class=""></div><div class="">Karl</div></body></html>