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

[Dave Abrahams]

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.
>
> Your comments and Erica’s comments have convinced me, or at least
> lessened my concerns, on all but split(…), but the higher-level point
> that we need naming guidelines for different kinds of closure
> parameters still stands.

Great, please propose some!

My feeling is that we can only discover what these guidelines should be
by solving individual naming problems (in groups, as here).

-- 
Dave