<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 Jul 7, 2016, at 5:03 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md</a> ]</div><div class=""><br class=""></div><div class="">Hi, Dave, Dmitri, Max. Sorry I didn’t make the pre-review commentary thread. I find I’m still not happy with several of these names, although there are many other improvements. Stepping back, I think the Swift API guidelines just don’t do a good job with closure parameters. We should have naming guidelines for strategy closures and for callbacks.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><u class="">lines.split(whereSeparator: isAllWhitespace)</u></div><div class=""><br class=""></div><div class="">This reads like an English sentence, but it doesn’t have the correct meaning for me. This implies a structure that has a pre-existing “separator", and checks if that separator matches the predicate, rather than searching for an element that matches the predicate, and splitting on that. I realize that the former reading doesn’t make much sense as a function, but it’s still impeded my understanding more than helping it along.</div><div class=""><br class=""></div><div class="">Alternate suggestions: split(where:), split(separatingWhere:).</div></div></div></blockquote><div><br class=""></div><div>I think split(where:) is the cleaner and more elegant choice. </div><div><br class=""></div><div>(But get ready, I'm about to defend Dave A's decisions from here forward)</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=""></div><div class=""><br class=""></div><div class=""><u class="">The sort(by:) family</u></div><div class=""><u class=""><br class=""></u></div><div class="">…seems fine, is slightly confusable with a “sort by key” API, but at least has a different type signature.</div></div></div></blockquote><div><br class=""></div><div>The obvious choices are `by`, `where`, and `with` but I like `by`. It tells the </div><div>story that this is a closure that's going to do the donkey's work for the sort.</div><div><br class=""></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=""><u class="">if roots.contains(where: isPrime) {</u></div><div class=""><br class=""></div><div class="">I really don’t like this one; it feels like it’s missing a noun. It certainly isn’t a valid English phrase. If we were naming an intersects(_:)-like feature, we might call it `roots.containsAny(of: primes)` or `roots.contains(anyOf: primes)`.</div></div></div></blockquote><div><br class=""></div><div>This isn't perfect but it's a lot cleaner than a lot of the alternatives that came up</div><div>in discussion. I'm happy with this one too. It differentiates contains(_:) from </div><div>contains(where:) and describes what the param does. I think it's solid enough</div><div>to hold its weight in the language.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Alternate suggestions: containsAny(where:), contains(anyWhere:)</div></div></blockquote><div><br class=""></div>Let me point out that "anywhere" jumps out, taking away from any positives this </div><div>would add. I get your point, but once you see "anywhere", you can't unsee it.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><u class="">if expected.elementsEqual(actual, by: haveSameValue)</u></div></div></blockquote><div><br class=""></div><div>I'm okay with `by`. I'm okay with `where`. But I think `by` is better in this </div><div>case because you're doing something to figure out. </div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I tend to agree with the <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/22188" class="">pre-review commentary</a> that “by:” doesn’t actually fit here. The difference between elementsEqual(_:by:) / starts(with:by:) and the sort(by:) family is that “sort by…” and “order by…” are both things people actually say, but “equal by…” is not. Then again, when they say those things, they’re either talking about a key (“sort by name”) or a general comparison (“sort by compar[ing] names”, <=> rather than <).</div></div></blockquote><div><br class=""></div><div>But you do say "equate by"</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><u class="">let sum = measurements.reduce(0, +)</u></div><div class=""><br class=""></div><div class="">It concerns me that we can’t think of a label for this operation; it implies we can’t think of an English sentence to describe it. “Reduce this collection to a single element by combining using +.” reduce(startingWith:combiningWith:) is pretty unwieldy, though.</div></div></blockquote><div><br class=""></div><div>This is short, sweet, and beautiful, lending itself to simple operators. When a </div><div>more complex routine is needed, it's perfect for trailing closures. I think it's a</div><div>great choice.</div><br class=""></div><div>-- E, really positive about this proposal</div><div><br class=""></div><br class=""></body></html>