<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=""><div class=""><br class=""></div><div class="">I like `mapSome`:</div><div class=""><br class=""></div><div class="">* `mapSome` uses conventional Swift terminology.&nbsp;</div><div class="">* It makes the outcome and expectations clear.&nbsp;</div><div class="">* As a bonus, it combines the English meaning of "some" ("map across some of these items", as in creating a filtered result) and the `Optional` case name.&nbsp;</div><div class=""><br class=""></div><div class="">In response to John's "<span style="font-family: Palatino-Roman;" class="">mapSome and especially mapNonNil both sound to me like they only map the non-nil values in the source sequence.", I'd respond that &nbsp; the mode of action is:</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">1. apply the function</span></div><div class=""><span style="font-family: Palatino-Roman;" class="">2. retrieve `some` cases&nbsp;</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">Selecting `mapSome` reflects those two stages. There is, however, Kevin's (sound) point against that it "</span><span style="font-family: Palatino-Roman;" class="">sounds like it takes a sequence of optionals and only modifies the non-nil values", but I still like it. &nbsp;</span><span style="font-family: Palatino-Roman;" class="">Some of the suggestions built around unwrapping address John's concern, for example `mapUnwrapped` but fail to distinguish between the `some` and `nil` cases, suggesting perhaps a catastrophic outcome for nil values.</span></div><div class=""><br class=""></div><div class="">I could live with many of the other names but I dislike `compact` (it has no precedent, sets an expectation of the implementation which may not match reality). Similarly `mapReduce` or `mapReducing` (which I prefer to `reduceMap`) may overburden the expectation of the existing `reduce`, where a user thinks prior results feed into the output, which they don't. &nbsp;I moderately like `mapSelective` (over `selectiveMap`) but I like it less than `filterMap`, `mapFiltering`, or `mapFiltered` and `mapSome`, all of which use Swift terms of art in their naming. (Also note&nbsp;<span style="font-family: Palatino-Roman;" class="">Gwendal's finding that as a term of art, it has "a&nbsp;</span><span style="font-family: Palatino-Roman;" class="">different signature, and a different meaning" in RxSwift.)</span></div><div class=""><br class=""></div><div class="">Summary:</div><div class=""><br class=""></div><div class="">* I like `mapSome`</div><div class="">* I'm fine with a `filter` variation, of which I prefer `mapFiltered`</div><div class=""><br class=""></div><div class="">-- E, former supporter of `filterMap` before `mapSome` entered her awareness</div><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2017, at 2:15 PM, Ben Cohen via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I continue to favour mapSome, since it’s both literally and figuratively what it does, but appreciate that exposing the name of the Optional.some case isn’t to everyone’s taste.<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello, Swift Community!<div class=""><br class=""></div><div class="">The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through yesterday, November 14th, 2017. &nbsp;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><div class="">There was a significant amount of discussion, and people came down with reasonable arguments both for and against the proposal. &nbsp;After reviewing that feedback, the core team feels that the central question is whether Swift benefits from overloading flatMap in this way. &nbsp;There is a reasonable argument that an Optional is a sort of container, and therefore it makes sense to "flatten" that container into a surrounding container. &nbsp;But Swift has resisted applying that interpretation in its library design; for example, you cannot directly iterate an Optional or append its contents to an Array. &nbsp;In general, we feel that using different operations for working with Optionals tends to make code easier to both write and understand, especially given the existence of implicit optional promotion, which we cannot eliminate or easily suppress based on the context. &nbsp;On reflection, we think it was a mistake to use the same name in the first place, and there is no better time to fix a mistake than now.</div><div class=""><br class=""></div><div class="">While we accept that this will cause some amount of "code churn" for developers when they adopt Swift 5, the required change is a simple rename that should be painless to automatically migrate. &nbsp;Of course, sample code on the internet will become obsolete, but fix-its will easily update that code if pasted into a project, and the samples themselves (once corrected) should become clearer and easier to teach after this change, as is generally true when overloading is removed.</div><div class=""><br class=""></div><div class="">Accordingly, SE-0187 is <b class="">accepted</b>, at least as far as not calling the operation "flatMap". &nbsp;We are re-opening the review until next Monday, November 20th, 2017, in order to have a focused discussion about the new name. &nbsp;Names that seemed to gain some traction in the first review include:</div><div class=""><br class=""></div><div class="">&nbsp; - filterMap, which has precedent in existing functional languages, as well as some popular Swift libraries, but which some people view as confusing</div><div class=""><br class=""></div><div class="">&nbsp; - compactMap, which builds off the precedent of "compact" in Ruby</div><div class=""><br class=""></div><div class="">But please feel free to suggest a name other than these.</div><div class=""><br class=""></div><div class=""><b class="">Reviews</b></div><div class=""><br class=""></div><div class=""><div class="">Reviews are an important part of the Swift evolution process. &nbsp;All reviews should be sent to the swift-evolution mailing list at</div><div class=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote><br class="">or, if you would like to keep your feedback private, directly to me as the review manager. &nbsp;When replying, please try to keep the proposal link at the top of the&nbsp;message:<br class=""><br class=""><blockquote class="" style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 1em; border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229); background-color: rgb(255, 255, 255);"><p class="" style="color: rgb(106, 115, 125); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; box-sizing: border-box; margin-top: 0px; margin-bottom: 16px;">Proposal link:</p><blockquote class="" style="box-sizing: border-box; margin: 0px; padding: 0px 1em; border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229);"><font size="3" 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></font></blockquote></blockquote><blockquote class="" style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 1em; color: rgb(106, 115, 125); border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><div class="" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;">Reply text</div></blockquote><blockquote class="" style="box-sizing: border-box; margin: 0px 0px 16px; padding: 0px 1em; color: rgb(106, 115, 125); border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><blockquote class="" style="box-sizing: border-box; margin: 0px; padding: 0px 1em; border-left-width: 0.25em; border-left-style: solid; border-left-color: rgb(223, 226, 229);"><div class="" style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px;">Other replies</div></blockquote></blockquote><b class="">What goes into a review?</b><br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.<div class=""><br class=""></div><div class="">When writing your review, here are some questions you might want to answer in your review:<br 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 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 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 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 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 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</div></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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></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=""></div></blockquote></div><br class=""></body></html>