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

Dave Abrahams dabrahams at apple.com
Fri Jul 8 11:56:07 CDT 2016

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


More information about the swift-evolution mailing list