[swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels

[Erica Sadun]

On Jul 8, 2016, at 10:56 AM, Dave Abrahams <dabrahams at apple.com> wrote:
> 
> 
> on Fri Jul 08 2016, Jordan Rose <jordan_rose-AT-apple.com> wrote:
> 
>>>> 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:).
>>> 
>>> Split(where:) fails to imply that there are separators (and that some
>>> elements would be omitted from the result), but we considered the second
>>> one.  I like the way it reads better, 
> 
> Actually I take that back.  It still fails to imply that there are
> separators and elements may be omitted.
> 
>>> but “whereSeparator” has the advantag of containing the word
>>> “separator” that's used in the predicate-free version.  For me it's a
>>> bit of a toss-up.

split(withLossySeparator:) ??

 (I hate this but there's a point to be made that naming dangerous 
operations trumps simple names and the other optional external
parameter names aren't exactly trim)

-- E