> On Jul 7, 2016, at 17:57, Dave Abrahams <[email protected]> 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. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
