[swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

[Sam Warner]

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 valuable, IMO, for people who are new to
Swift in being able to form an understanding of what these functions do,
and also for library authors who are creating box types and want
discoverable, intuitive API names.

This is the reason why I lean towards keeping `flatMap` and adding a
compiler warning for incorrect/redundant uses.

Cheers,

Sam

On Fri, 10 Nov 2017 at 05:43 BJ Homer <bjhomer at gmail.com> wrote:

>
> On Nov 9, 2017, at 11:35 AM, Tino Heth <2th at 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 should be really right: As I learned in the thread, there is a
> map step before filter, and another map afterwards - so
> „filterNonesAfterMappingAndMap“ (that’s why I don’t like the use of the
> term „filter“ here — if you want an accurate name that contains this verb,
> it gets quite complicated…)
>
>
> But obviously “filterNonesAfterMappingAndMap” is not a name we’re going to
> end up with. You can argue that “filterMap” is not completely faithful to
> the internal implementation, but I think it’s clearly better than “flatMap”
> in this case, which is even *more* incorrect. I’m not opposed to finding
> a better name than “filterMap”, but so far I haven’t seen one.
>
> -BJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171109/7001a7b4/attachment.html>