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 <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> Le 16 nov. 2017 à 06:29, Matt Gallagher via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>> [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
