I like `mapSome`:
* `mapSome` uses conventional Swift terminology.
* It makes the outcome and expectations clear.
* 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.
In response to John's "mapSome and especially mapNonNil both sound to me like
they only map the non-nil values in the source sequence.", I'd respond that
the mode of action is:
1. apply the function
2. retrieve `some` cases
Selecting `mapSome` reflects those two stages. There is, however, Kevin's
(sound) point against that it "sounds like it takes a sequence of optionals and
only modifies the non-nil values", but I still like it. 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.
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. 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 Gwendal's finding that as a term of art, it has
"a different signature, and a different meaning" in RxSwift.)
Summary:
* I like `mapSome`
* I'm fine with a `filter` variation, of which I prefer `mapFiltered`
-- E, former supporter of `filterMap` before `mapSome` entered her awareness
> On Nov 15, 2017, at 2:15 PM, Ben Cohen via swift-evolution
> <[email protected]> wrote:
>
> 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.
>
>> On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hello, Swift Community!
>>
>> The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran
>> through yesterday, November 14th, 2017. The proposal is available here:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md>
>>
>> There was a significant amount of discussion, and people came down with
>> reasonable arguments both for and against the proposal. After reviewing
>> that feedback, the core team feels that the central question is whether
>> Swift benefits from overloading flatMap in this way. 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. 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. 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. 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.
>>
>> 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. 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.
>>
>> Accordingly, SE-0187 is accepted, at least as far as not calling the
>> operation "flatMap". We are re-opening the review until next Monday,
>> November 20th, 2017, in order to have a focused discussion about the new
>> name. Names that seemed to gain some traction in the first review include:
>>
>> - filterMap, which has precedent in existing functional languages, as well
>> as some popular Swift libraries, but which some people view as confusing
>>
>> - compactMap, which builds off the precedent of "compact" in Ruby
>>
>> But please feel free to suggest a name other than these.
>>
>> Reviews
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> or, if you would like to keep your feedback private, directly to me as the
>> review manager. When replying, please try to keep the proposal link at the
>> top of the message:
>>
>> Proposal link:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>
>> <https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md>
>> Reply text
>> Other replies
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and, eventually, determine the direction of
>> Swift.
>>
>> When writing your review, here are some questions you might want to answer
>> in your review:
>>
>> • What is your evaluation of the proposal?
>> • Is the problem being addressed significant enough to warrant a change
>> to Swift?
>> • Does this proposal fit well with the feel and direction of Swift?
>> • If you have used other languages or libraries with a similar feature,
>> how do you feel that this proposal compares to those?
>> • How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>> More information about the Swift evolution process is available at:
>>
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>>
>> As always, thank you for contributing to the evolution of Swift.
>>
>> John McCall
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
