[swift-evolution] Stdlib closure argument labels and parameter names

[Dave Abrahams]

on Mon Jun 27 2016, Xiaodi Wu <swift-evolution at swift.org> wrote:

> On Mon, Jun 27, 2016 at 9:10 AM, Dave Abrahams
> <dabrahams at apple.com> wrote:
>
>>
>> on Sun Jun 26 2016, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>>
>> > On Sun, Jun 26, 2016 at 2:18 PM, Erica Sadun via swift-evolution <
>> > swift-evolution at swift.org> wrote:
>> >
>> >>
>> >> See below.  But in a nutshell, `do` gets the idea across. It's short.
>> >> It's pithy.  It uses a common, comfortable word. So yes, personal
>> >> taste. But it's personal taste backed up by some statistics.
>> >>
>> >
>> > I've made this comment previously in another thread, but I'll chime in
>> here
>> > because it seems pertinent. Just like the parentheses around function
>> > arguments can imply the word "with" or "using," 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 "do," "invoke,"
>> > "perform" or even "soEach." After all, it's absurd that a closure would
>> be
>> > supplied as an argument for any purpose other than being done or invoked
>> or
>> > performed.
>>
>> Not at all.
>>
>>     callbacks.append( { print("ring ring") } )
>>
>
> 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? 

Maybe, eventually, someday.  But that's not at all the role it plays in
append.

> Would you find value in having it rewritten `callbacks.append(callee:
> { print("ring ring") })`?

No, that's my point!

>> > 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.
>>
>> I totally buy that argument when it comes to `do` or `body`.  That said,
>> as I have pointed out many times, “soEach” has very specific
>> communicative value that none of these others do.
>
> I get what you're aiming for with "soEach." So that we're on the same page,
> here's what I think you think:
>
> (1) "so" communicates that, in the case of filtering, the elements that
> satisfy the predicate are kept rather than discarded
> (2) "each" communicates that the predicate operates on an individual
> element at a time

“each” is just what's required to make “so” read sensibly.

    (0..<100).filter(so: isPrime)

doesn't make any obvious sense.

> Regarding (2)--I think clarifying this isn't extremely valuable, because:
>
> 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.

Yes, because that's the way the language works for first.  It doesn't
work that way in this case.

> 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.
>
> 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, 

More so!

> I would propose the following:
>
> 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.

Yes, as I've said, we should change the base name to “where” and drop
the label.  But that's out of scope for this proposal.

> 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.
>
> 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).

-- 
-Dave