[swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels
jordan_rose at apple.com
Fri Jul 8 11:41:51 CDT 2016
> On Jul 7, 2016, at 17:57, Dave Abrahams <dabrahams at apple.com> wrote:
> on Thu Jul 07 2016, Jordan Rose <jordan_rose-AT-apple.com <http://at-apple.com/>> wrote:
>> [Proposal: 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:).
> 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, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution