<div dir="ltr">On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></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"><span class=""><br>
on Sun Jun 26 2016, Xiaodi Wu <<a href="http://xiaodi.wu-AT-gmail.com" rel="noreferrer" target="_blank">xiaodi.wu-AT-gmail.com</a>> wrote:<br>
<br>
> On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
</span><span class="">>> See below. But in a nutshell, `do` gets the idea across. It's short.<br>
>> It's pithy. It uses a common, comfortable word. So yes, personal<br>
>> taste. But it's personal taste backed up by some statistics.<br>
>><br>
><br>
> I've made this comment previously in another thread, but I'll chime in here<br>
> because it seems pertinent. Just like the parentheses around function<br>
> arguments can imply the word "with" or "using," and just as Swift 3 renamed<br>
> `foo(atIndex: Int)` to `foo(at: Int)` because an argument of type Int<br>
> implies an index, a closure to me implies the word "do," "invoke,"<br>
> "perform" or even "soEach." After all, it's absurd that a closure would be<br>
> supplied as an argument for any purpose other than being done or invoked or<br>
> performed.<br>
<br>
</span>Not at all.<br>
<br>
callbacks.append( { print("ring ring") } )<br></blockquote><div><br></div><div>I'm not sure I understand. Your closure here would be a callback, as in you expect it to be called or done or invoked, no? Would you find value in having it rewritten `callbacks.append(callee: { print("ring ring") })`?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> That a label such as `do` or `body` or `soEach` could be applied so<br>
> broadly seems to me a good sign that these labels might be extraneous.<br>
<br>
</span>I totally buy that argument when it comes to `do` or `body`. That said,<br>
as I have pointed out many times, “soEach” has very specific<br>
communicative value that none of these others do.<br></blockquote><div><br></div><div>I get what you're aiming for with "soEach." So that we're on the same page, here's what I think you think:</div><div><br></div><div>(1) "so" communicates that, in the case of filtering, the elements that satisfy the predicate are kept rather than discarded</div><div>(2) "each" communicates that the predicate operates on an individual element at a time</div><div><br></div><div>Regarding (2)--I think clarifying this isn't extremely valuable, because:</div><div><br></div><div>A. That a property or method has to do with an individual element of a sequence/collection is frequently understood by implication in property and method names. For example: `first` isn't `firstElement`; it's simply understood.</div><div><br></div><div>B. In plain English, we frequently understand that a verb used in relation to a thing with multiple constituent parts operates on said constituent parts one-by-one.</div><div><br></div><div>Regarding (1)--I agree that knowing whether elements satisfying the predicate are kept or discarded, etc., is essential. I'll call this the "keeping vs. discarding" issue. That said, since trailing closure syntax allows the label to be omitted, and since we take into consideration clarity for the reader at the call site as much as clarity for the writer at the time of reading the documentation, I would propose the following:</div><div><br></div><div>A. If "keeping vs. discarding" is ambiguous from the base name (or at least, the full method name minus the predicate's label), then clarifying words should be inserted somewhere other than the label so that the same clarity can be assured at any call site.</div><div><br></div><div>B. If "keeping vs. discarding" is unambiguous without taking into consideration the predicate's label, it's extraneous to reiterate the point in the label.</div><div><br></div><div>C. I question whether there really exist scenarios that are not important enough to justify (A) but just unclear enough that (B) is unsatisfactory; where reasonable people differ, I propose erring on the side of caution and going with (A).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
-Dave<br>
</font></span></blockquote></div><br></div></div>