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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
