> On Jul 7, 2016, at 5:03 PM, Jordan Rose via swift-evolution
> <[email protected]> wrote:
>
> [Proposal:
> https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md
>
> <https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md>
> ]
>
> 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.
>
>
> lines.split(whereSeparator: isAllWhitespace)
>
> 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.
>
> Alternate suggestions: split(where:), split(separatingWhere:).
I think split(where:) is the cleaner and more elegant choice.
(But get ready, I'm about to defend Dave A's decisions from here forward)
>
>
> The sort(by:) family
>
> …seems fine, is slightly confusable with a “sort by key” API, but at least
> has a different type signature.
The obvious choices are `by`, `where`, and `with` but I like `by`. It tells the
story that this is a closure that's going to do the donkey's work for the sort.
> if roots.contains(where: isPrime) {
>
> 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)`.
This isn't perfect but it's a lot cleaner than a lot of the alternatives that
came up
in discussion. I'm happy with this one too. It differentiates contains(_:) from
contains(where:) and describes what the param does. I think it's solid enough
to hold its weight in the language.
> Alternate suggestions: containsAny(where:), contains(anyWhere:)
Let me point out that "anywhere" jumps out, taking away from any positives this
would add. I get your point, but once you see "anywhere", you can't unsee it.
> if expected.elementsEqual(actual, by: haveSameValue)
I'm okay with `by`. I'm okay with `where`. But I think `by` is better in this
case because you're doing something to figure out.
>
> I tend to agree with the pre-review commentary
> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/22188> 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 <).
But you do say "equate by"
> let sum = measurements.reduce(0, +)
>
> 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.
This is short, sweet, and beautiful, lending itself to simple operators. When a
more complex routine is needed, it's perfect for trailing closures. I think
it's a
great choice.
-- E, really positive about this proposal
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
