<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 8 Nov 2017, at 7:23 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hello, Swift community!<div class=""><br class=""></div><div class="">The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs through November 14th, 2017. The proposal is available here:</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md</a></div></blockquote><div class=""><br class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• What is your evaluation of the proposal?<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>It is a welcomed change provided that it does help with future integrity of the affected APIs.</div><div><br class=""></div><div>But I am not sure that the solution is the best fit. It bends over the API while apparently the crux is the implicit optional promotion. Shouldn’t we consider the feasibility of disabling the promotion for this specific overload before proceeding with renaming? This wasn’t addressed in the proposal.</div><div><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></div></blockquote><div><br class=""></div><div>Yes. I agree that the unintended hole caused by future collection conformances and optional implicit promotion should be mitigated.</div><div><br class=""></div><div>But in principle, I don’t see a problem with all of them being called `flatMap`, since `Optional` is effectively a 0- or 1-element collection, just without the `Collection` conformance.</div><div><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></div></blockquote><div><br class=""></div><div>Yes.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></div></blockquote><div><br class=""></div><div>ReactiveSwift calls this operation `filterMap` too (but operating on a reactive stream instead). As far as I could recall, we picked this name since (1) the operation is effectively map-then-filter; (2) it is named the same by Erlang, Elm, Rust, etc; and (3) we see no point to pull in new verbs to convey the meaning.</div><div><br class=""></div><div>Some have expressed concerns about `filterMap` being the reverse of the actual operation (i.e. map-then-filter). While I have no exact idea of why `flatMap` was picked instead of `mapFlatten` by the early FP communities, my perception of the reasoning is that `mapFlatten(transform)` would be perceived as `mapFlattened` at first glance due to the LTR writing order.</div><div><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></div></blockquote><div><br class=""></div><div>A quick reading since these APIs are often used daily.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><br class=""></div>More information about the Swift evolution process is available at:<div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></div></blockquote><div class=""><br class="">As always, thank you for contributing to the evolution of Swift.<br class=""><br class="">John McCall<br class="">Review Manager<br class=""></div></div></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><div class=""><br class=""></div></body></html>