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