[swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

[Gwendal Roué]

Yes, you are right. I was too fast.

I've been thinking why filterMap has such a traction in the community, despite the fact that this precise "filter" is a tiny subset of the "filter" generally used by the language.

I think "filterMap" clicks well in many readers because of this trend of thought:

1. I need to transform some values and only keep some of them. But I don't want to use `seq.filter { ... }.map { ... }` or `seq.map { ... }.filter { ... }`. I don't even want to think about the ordering of the filter and mapping operations: that's not interesting. I want a versatile filter+map operation that I'll call "filterMap".
2. Now I need a closure that returns a two-state value: either (in+value), or (out).
3. Which existing Swift type fits such a requirement? Optional, of course. The optional itself will stand for the boolean needed by the filtering operation. The wrapped value will give the mapped value. Pretty efficient.

This trend of thought starts from an actual need (I don't know how to call it) and builds a rationale for it to use the words "filter", "map", and the Optional type. It uses optionals as booleans, which is a venial sin. It happens to build a 100% compatible replacement for the old "flatMap".

The "compact" trend of thought introduces a new operation which filter out nils. It happens to build a 100% compatible replacement for the old "flatMap".

The previous trend of thought (flatMap) did consider optionals as collections. It happens to confuse people, and has been rejected.

The three ways of thinking build the same function. I've been pushing "compact" has a way to better explore the subject. But I really don't know how the Swift community prefers to wire the developer's brains.

Gwendal



> Le 16 nov. 2017 à 09:12, Anders Ha <anders at andersha.com> a écrit :
> 
> It does not use `Optional`, but it is semantically equivalent to `filterMap` in CwlSignal and ReactiveSwift, and the `filterMap` proposed for `Sequence` (but in the time domain instead).
> 
> 
> 
> Regards,
> Anders
> 
> 
> 
>> On 16 Nov 2017, at 2:07 PM, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> My opinion is that filterMap is the right choice of name.
>>> 
>>> I'm completely biased, given that I already have a Swift library that uses filterMap, in exactly this context, for a Reactive Programming library:
>>> 
>>> 	https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3 <https://github.com/mattgallagher/CwlSignal/blob/22f1d47895896d7b55bc59a4ee5394071f3c84cf/Sources/CwlSignal/CwlSignalReactive.swift#L453?ts=3>
>> 
>> Another popular Reactive Programming Library uses filterMap with a different signature, and a different meaning: https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32 <https://github.com/RxSwiftCommunity/RxSwiftExt/blob/3.0.0/Source/RxSwift/filterMap.swift#L32>
>> 
>> There are already different interpretations on "filter" in "filterMap" in the wild.
>> 
>> Gwendal Roué
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171116/9f1df349/attachment.html>