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

[Dave Abrahams]

on Wed Jun 29 2016, Erica Sadun <erica-AT-ericasadun.com> wrote:

>> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> I've updated my pull request with a much more conservative set of
>> changes that preserves/restores label-free-ness for all “term of art”
>> functional methods such as filter and reduce.
>> 
>> https://github.com/apple/swift/pull/2981
>> 
>> My current thoughts are that many of the `by:` labels are awkward and
>> not adding much.  Perhaps they all ought to be omitted.
>
> I'd be happy to see `by` labels go away, whether first or
> trailing. I'm not sure why Swift 3 wants to have so many extra labels
> when a very simple phrase is understandable on its own (e.g. max, min,
> sort, sorted).

Well, it's simple: the labels aren't extra because x.sort(y) sounds like
x is sorting y.

> Is it possible under the Swift umbrella to do the same for split since
> it has the rarely used maxSplits, and omittingEmptySubsequences
> params? 

? AFAICT a decision about dropping the label has nothing to do with
those other parameters

> It would give you `split({$0 == " "})` and `split(atWhitespace)`.

It wouldn't, because your predicate that identifies whitespace is not
going to be called, “atWhitespace”

> Speaking of isAllWhitespace, would this be a prebuilt enumeration or
> is it a placeholder?

It's not an enumeration; we're talking about closure parameters,
remember?  It's a hypothetical predicate:

   func isAllWhitespace(_: String) -> Bool

> If the former, I have opinions (new lines, new lines and whitespace)
>
> The managed buffer, are you "makingValueWith" instead of
> "makingHeaderWith" intentionally?

Yes, because the change from “Value” to “Header” is a separate proposal
that you have kindly written up for me.

> If so, no worries. If not, helpful ping.
>
> Future Extensions:
>
> * reduce(_:, combine:)  // way simpler
>
> * "The argument against changing other names to be more consistent with API guidelines 
> is weakened. "
>
>  I think Sean Heber's `@termOfArt(name)` is a great way to have both worlds, where 
> `select(where:)` or `where()` is the Swifty name and `@termOfArt(filter)` offers
> a substitutable alias for fp aficionados. 
>
> This approach is not anything I've ever seen previously in a programming language but 
> its something that jumps out as a way to satisfy two distinct audiences of users
> that would have limited impact but a decided advantage.
>
> That said, I don't like `mapping` and `flattened`. If they're going to be Swiftized, go with
> names that aren't standing in the "term of art" rubble: transform, squeeze, whatever.

Separate discussion, but thanks for the input.  Let's handle that stuff
in a separate review.  I should probably strip it out of the pull
request text.

-- 
Dave