Hello,
I cast my vote for compactMap. And I wish for another proposal for the plain
non-mutating method `compacted`.
Some say that compact has no precedent in Swift, and is ambiguous.
"Compact" has no precedent because it names an operation which had no name yet:
filtering out nils. Is is only as ambiguous as one resists mapping "compact" to
"filter out nils".
Suggesting "compact" is suggesting that we acknowledge that filtering out nils
is a very common operation which deserves its own name. Hence the wish for
`array.compacted()` as a shorthand for `array.compactMap { $0 }`.
Suggesting "compact" is suggesting that we stop using the functional
programming vocabulary for an operation that does not quite fit this model, as
functional experts here have reminded several times.
"Compact" is not an attempt at piling up existing Swift words until they build
"filtering out nils". That's three words. "Compact" elegantly compacts them all
in a single word that is easy to learn, and remember.
"filterMap" forgets about nil checking. To support "filterMap", some claim that
"filter" is OK because it means "reduce the size of an array". OK, but we are
still missing "nils".
“unwrappingMap”, "mapAndUnwrap", "mapUnwrappingSome", "mapUnwrapSome",
"mapUnwrapIfSome", and generally names around "unwrap": those are serious
candidates. But what could be the natural shortening for `array.unwrappingMap {
$0 }`? `array.unwrapped()`? What does it mean to "unwrap" a collection?
"mapSome" does not do what it claims: it maps, then keeps the some, instead of
mapping the some.
"mapNonNil": same as above
"selectiveMap": it would be OK if "selecting" would be defined as "filtering
out nils". Yet "compact" is better at this job, because "compacting" already,
in English, means compressing by removing voids. "Selecting", in English, is a
synonym for "filtering", and is less good as "compact", assuming we acknowledge
introducing a new word in the Swift vocabulary for the "filtering out nils"
operation.
“mapDroppingNil”, "mapStrippingNil" : now it's a matter of taste :-)
Gwendal Roué
Sorry for the not-so-compact reply
>
> Le 15 nov. 2017 à 21:55, John McCall via swift-evolution
> <swift-evolution@swift.org> a écrit :
>
> 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 mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
