<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="">On Jun 25, 2016, at 4:25 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:<br class=""><div><blockquote type="cite" class="">on Wed Jun 22 2016, Erica Sadun <<a href="http://erica-at-ericasadun.com" class="">erica-AT-ericasadun.com</a>> wrote:<br class=""><div class=""><div class="">On Jun 20, 2016, at 3:25 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<blockquote type="cite" class="">- func forEach<S: SequenceType>(_ body: (S.Iterator.Element) -> ())<br class="">+ func forEach<S: SequenceType>(invoke body: (S.Iterator.Element) -> ())<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><br class=""></div><div>When using a procedural "trailable" closure inside parentheses, the intention</div><div>to do so should be clear:</div><div><br class=""></div><div><font face="Menlo" class="">p(x, perform: {...})</font></div><div><font face="Menlo" class="">p(x, do: {...})</font></div><div><br class=""></div><div>vs</div><div><br class=""></div><div><font face="Menlo" class="">p(x) {</font></div><div><font face="Menlo" class=""> ...</font></div><div><font face="Menlo" class="">}</font></div><div><br class=""></div><div>Anyone reading this code can immediately identify that an otherwise trailing</div></div><div>closure has been pulled inside the signature because the call has become </div><div>significantly more complex. The point-of-coding decision ripples through</div><div>to point-of-reading/point-of-maintenance.</div><div><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. 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`? <br class=""></div></div></blockquote><div><br class=""></div><div>I read through the pull request. I grouped related modifications</div><div>together, although not exhaustively. They fall under the same umbrella, </div><div>choosing `do` or `perform` compared to `invoke` or `invoking`.</div><div><br class=""></div><div><div><font face="Menlo" class="">- _forAllPermutationsImpl(index + 1, size, &perm, &visited, body)</font></div><div><font face="Menlo" class="">+ _forAllPermutationsImpl(index + 1, size, &perm, &visited, <b class="">invoke</b>: body)</font></div><div><font face="Menlo" class=""><br class=""></font></div></div><div><div><font face="Menlo" class="">-public func runRaceTest(trials: Int, threads: Int? = nil, <b class="">body</b>: () -> ()) {</font></div><div><font face="Menlo" class="">+public func runRaceTest(</font></div><div><font face="Menlo" class="">+ trials: Int, threads: Int? = nil, <b class="">invoking</b> body: () -> ()</font></div><div><font face="Menlo" class="">+) {</font></div></div><div><font face="Menlo" class=""><br class=""></font></div><div><div><font face="Menlo" class="">-public func expectFailure(${TRACE}, <b class="">body</b>: () -> Void) {</font></div><div><font face="Menlo" class="">+public func expectFailure(${TRACE}, <b class="">invoking</b> body: () -> Void) {</font></div><div><br class=""></div><div><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><br class=""></div><div>You did, as in the examples just above, which you recommend a rename to `invoke` or</div><div>`invoking`.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">-public func withInvalidOrderings(_ body: ((Int, Int) -> Bool) -> Void) {<br class="">+public func withInvalidOrderings(invoke body: ((Int, Int) -> Bool) -> 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. Is there a rationale, or is it just personal taste?<br class=""></div></div></blockquote><div><br class=""></div><div>Strong personal taste, backed by tech writing. Simpler words. </div><div>From the Corpus of Contemporary American English:</div><div><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="">- return IteratorSequence(it).reduce(initial, combine: f)<br class="">+ 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. You're not comparing the closure with<br class="">anything.<br class=""></div></div></blockquote><div><br class=""></div><div>I get your point but I think it's unnecessarily fussy. </div><div><br class=""></div><div>Alternatives are slim on the ground. `usingComparison:` is too long,</div><div>as is `byComparingWith:` (which still reads better but you will point</div><div>out can be mistaken by some pedant to mean that the sequence is being</div><div>compared to the closure), and you won't allow for `comparing:`.</div><div>I'm not in love with `comparingWith:` but it reads slightly better to me </div><div>than `comparingBy:`.</div><div><br class=""></div><div><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><br class=""></div>Same reasoning.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- ).encode(encoding, output: output)<br class="">+ ).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. In fact it doesn't mean anything more exotic than<br class="">“sending output to.”<br class=""></div></div></blockquote><div><br class=""></div><div>For a language that treasures concision and clarity, this may be clear</div><div>but it's notably inconcise. (Yes, that is a new word.)</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- tempwords.sort(isOrderedBefore: <)<br class="">+ tempwords.sort(orderingBy: <)<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. Therefore IMIO that label should probably be<br class="">reserved for a version that takes a unary projection function:<br class=""><br class=""> friends.sort(by: {$0.lastName})<br class=""></div></div></blockquote><div><br class=""></div><div>But they're sorting now, and that feature isn't in Swift.</div><div><br class=""></div><div>However, `sorted` falls under another umbrella, which is potential</div><div>chaining. In such case, I would prefer there be no internal label at all</div><div>to allow cleaner functional flow.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">- if !expected.elementsEqual(actual, isEquivalent: sameValue) {<br class="">+ 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><br class=""></div><div>I actually meant to move this up to the other discussion of `byComparing` and</div><div>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="">- /// for which `predicate(x) == true`.<br class="">+ /// for which `isIncluded(x) == true`.<br class="">- _base: base.makeIterator(), whereElementsSatisfy: _include)<br class="">+ _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><br class=""></div><div>I like `predicate`. I endorse `predicate`. Does this mean the rule of "must</div><div>read like a sentence" can be overturned for things like "comparison" and</div><div>"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><br class=""></div><div>To quote greatness:, "I personally find `soEach` repulsive".</div><div>(cite: <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="">- || u16.contains({ $0 > 127 || _isspace_clocale($0) }) {<br class="">+ || u16.contains(elementWhere: { $0 > 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. 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. I'm truly not sure where we<br class="">ought to land on this one.<br class=""></div></div></blockquote><div><br class=""></div>May I recommend `predicate:` then since it looks like that's actually a possibility?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> - let result = try base._withUnsafeMutableBufferPointerIfSupported(body)<br class="">+ 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. It's also an internal API so it's not an evolution issue. 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><br class=""></div><div>Woody Allen: "The heart wants what it wants"</div><div>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="">- for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) {<br class="">+ for test in removeFirstTests.filter(<br class="">+ 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. 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><br class=""></div><div>Functional programming flow. I follow Kevin Ballard's rule of parens around</div><div>functional elements and naked braces for trailing closures that do not return</div><div>values. This ensures the compiler is never confused at places like:</div><div><br class=""></div><div><font face="Menlo" class="">for x in foo when y.f{...} {</font></div><div><font face="Menlo" class=""> ...</font></div><div><font face="Menlo" class="">}</font></div><div><br class=""></div><div>and instantly identifies to the reader when there's a non-returning scope, as</div><div>in forEach or GCD dispatch.</div><div><br class=""></div><div>However, if you use chaining and if the language insists on external label </div><div>preambles, which would not be seen when using the call with a trailing closure,</div><div>it becomes far less readable and encourages people to use trailing closures to </div><div>avoid the label, i.e. an attractive nuisance. Simple selectors encourage better fp:</div><div><br class=""></div><div><font face="Menlo" class="">let x = myStream.f1({...}).f2({...})</font></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">public func split(<br class=""> maxSplits: Int = Int.max,<br class=""> omittingEmptySubsequences: Bool = true,<br class="">- isSeparator: @noescape (Base.Iterator.Element) throws -> Bool<br class="">+ separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws -> 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. I think this is very similar to the<br class="">`contains(elementWhere` vs `containsElement(where` discussion. 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><br class=""></div><div>`predicate` ftw.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">+ 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. 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><br class=""></div>It was humor. It was at the end. I assumed the joke would lighten the</div><div>previous complaints and bookend the positive support at the start of</div><div>my message.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">-Dave<br class=""></div></div></blockquote><br class=""></div><div>-- E</div><div><br class=""></div><br class=""></body></html>