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

[Xiaodi Wu]

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? Would you find value in
having it rewritten `callbacks.append(callee: { print("ring ring") })`?

> 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

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.

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160627/25399518/attachment.html>