> I like `predicate`. I endorse `predicate`. Does this mean the rule of "must > read like a sentence" can be overturned for things like "comparison" and > "order"? If so, woo!
I've suggested that a few emails back as well, but I've asked myself if it's not a bit confusing when you have (NS)Predicate - if it doesn't seem like something taking the Predicate object argument instead of a block. > >> >>> I get the `is` desire but it's being tossed away in a lot of other >>> places in this diff. and `suchThat` feels out of place. >> >> I think I'm pretty strongly sold on “soEach” as a label for closures in >> all the filtering components. > > To quote greatness:, "I personally find `soEach` repulsive". > (cite: > http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive > > <http://article.gmane.org/gmane.comp.lang.swift.evolution/16998/match=repulsive>) > >> >>> - || u16.contains({ $0 > 127 || _isspace_clocale($0) }) { >>> + || u16.contains(elementWhere: { $0 > 127 || _isspace_clocale($0) }) { >>> >>> I assume the challenge here is differentiating contains(element) from >>> contains(closure). >>> This feels predicate-y, which is why I put it near the predicates. But I >>> think something >>> like `containsElement(where:)` works better. >> >> I understand your motivation for suggesting it. The downside is that it >> severs the strong basename relationship between algorithms that do >> effectively the same things, one using a default comparison and the >> other using an explicitly-specified one. I'm truly not sure where we >> ought to land on this one. > > May I recommend `predicate:` then since it looks like that's actually a > possibility? > >> >>> - let result = try base._withUnsafeMutableBufferPointerIfSupported(body) >>> + let result = try >>> base._withUnsafeMutableBufferPointerIfSupported(invoke: body) >>> >>> I hate "ifSupported" >> >> Me too. >> >>> but that's another discussion >> >> Quite. It's also an internal API so it's not an evolution issue. The >> point of having that change as part of the diff (as with all the other >> use sites), is to observe how the changes affect real usage. > > Woody Allen: "The heart wants what it wants" > Me: "The spleen vents what it vents" > >> >>> (withSupportedUnsafeMutableBufferPointer, >>> withAvailableUnsafeMutableBufferPointer, it's all lipstick) >>> >>> This is procedural, so `do` or `perform` rather than `invoke` >>> >>> - for test in removeFirstTests.filter({ $0.numberToRemove == 1 }) { >>> + for test in removeFirstTests.filter( >>> + suchThat: { $0.numberToRemove == 1 } >>> >>> The difference between `filter` and `forEach` is that `forEach` is >>> explicitly >>> procedural while `filter` is functional. I do not like functional chainable >>> calls being modified to use explicit external labels in this way. >>> >>> I'd prefer no label here. >> >> Can you provide rationale for treating functional methods differently, >> or is it just personal taste? > > Functional programming flow. I follow Kevin Ballard's rule of parens around > functional elements and naked braces for trailing closures that do not return > values. This ensures the compiler is never confused at places like: > > for x in foo when y.f{...} { > ... > } > > and instantly identifies to the reader when there's a non-returning scope, as > in forEach or GCD dispatch. > > However, if you use chaining and if the language insists on external label > preambles, which would not be seen when using the call with a trailing > closure, > it becomes far less readable and encourages people to use trailing closures > to > avoid the label, i.e. an attractive nuisance. Simple selectors encourage > better fp: > > let x = myStream.f1({...}).f2({...}) > >> >>> public func split( >>> maxSplits: Int = Int.max, >>> omittingEmptySubsequences: Bool = true, >>> - isSeparator: @noescape (Base.Iterator.Element) throws -> Bool >>> + separatedWhere isSeparator: @noescape (Base.Iterator.Element) throws >>> -> Bool >>> >>> I'm torn on this one. It's not the worst ever but something more like >>> where/at/when >>> makes more sense to me than >>> "separatedWhere/separatedAt/separatedWhen". >> >> The biggest reason to keep “separate” in the name is the connection with >> the semantics of the other `split` method, that takes a single element >> that is tested for equality. I think this is very similar to the >> `contains(elementWhere` vs `containsElement(where` discussion. If you >> leave “separate” out of the name it fails to imply that those elements >> for which the predicate returns true are not present in the result. > > `predicate` ftw. > >> >>> >>> + count: __manager._headerPointer.pointee.count) >>> >>> For the sake of Zippy the Pinhead, surely there has to be something better >>> than `pointee`. >>> Like...`reference`? >> >> It's not a reference; it's a value. But that, my friend, is an >> *entirely* different discussion. Let's try to stick to the scope of the >> proposal: names and labels for parameters of function type, OK? > > It was humor. It was at the end. I assumed the joke would lighten the > previous complaints and bookend the positive support at the start of > my message. > >> >> -- >> -Dave > > -- E > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution