The typical case for this function in my code is the identity closure, that is
let a: [Int?] = ...
print(a.filterMap {$0})
filterMap is quite poor for this situation because *each* component in the term
is inaccurate:
1. While we are filtering in the "english sense", in Swift the word "filter"
carries a specific meaning involving booleans. In particular if `a` were of
type `[Bool?]` I believe new Swift programmers would fail to predict the result
2. This is not a map operation when used with the identity closure.
Most of the discussion so far addresses 1 but not 2, e.g. mapSome, mapCompact
improve dimension 1 but not dimension 2.
I support mapMaybe because from the choices so far it is the only one that
seems to address both dimensions.
It can also be argued that the combined API itself is a mistake, e.g. that a
distinct API for discarding optionals as from mapping would be superior. But
that may be too radical at this point.
On November 15, 2017 at 2:55:10 PM, John McCall ([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
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
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
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
As always, thank you for contributing to the evolution of Swift.
John McCall
Review Manager
_______________________________________________
swift-evolution-announce mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution-announce
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
