What I meant by flagging the renaming of the generic `flatMap` to the more
specific-to-this-case `filterMap` is that all of the current uses of
`flatMap` share conceptual details: they all process whatever is in the
box, then perform one level of flattening.
This shared concept is hugely
> On Nov 9, 2017, at 11:43 AM, Vladimir.S via swift-evolution
> wrote:
>
> let a : [Int?] = [1,2,3,nil,4,nil,5]
>
> let b = a.flatMap { $0.flatMap{$0*10} } // current
At the risk of taking us further down the rabbit hole…
You really want:
let b = a.flatMap {
On 09.11.2017 19:41, BJ Homer via swift-evolution wrote:
On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution
wrote:
I accept the motivation for this change, although I would mention that:
- in 2.5 years on a ~200k lines of Swift project
- we've seen a
>
> On Nov 9, 2017, at 11:35 AM, Tino Heth <2...@gmx.de> wrote:
>
>
>> This proposal only proposes renaming the “filterNonesAndMap” variant (though
>> that name is misleading, it would be “filterNonesAfterMapping” if anything);
>> the other uses of flatMap will remain unchanged.
> … then it
> This proposal only proposes renaming the “filterNonesAndMap” variant (though
> that name is misleading, it would be “filterNonesAfterMapping” if anything);
> the other uses of flatMap will remain unchanged.
… then it should be really right: As I learned in the thread, there is a map
step
> On Nov 9, 2017, at 9:37 AM, Sam Warner via swift-evolution
> wrote:
>
> I accept the motivation for this change, although I would mention that:
> - in 2.5 years on a ~200k lines of Swift project
> - we've seen a plenty of instances of `flatMap` used where `map`
I accept the motivation for this change, although I would mention that:
- in 2.5 years on a ~200k lines of Swift project
- we've seen a plenty of instances of `flatMap` used where `map` would have
been sufficient, but
- we've never burned time on tracking down the sort of compiler issue
described