I agree that filterMap is just as confusing and awkward as flatMap, if not
more. Filter works on Bools, not nils. It is just asking for
trouble/confusion, and I would hate to rename this again next year. If the
word ‘filter’ must be used, then I recommend using ‘filteringMap()’ to lessen
confusion with the filter method.
I like the idea of introducing compacted() and compactedMap(), though it only
works if we introduce compacted() at the same time (which I am ok with). I
keep expecting it to be a compact map in the topological sense, but I doubt
that is a problem most will have.
The only real way to get forward transfer here (besides leaving it alone) is to
do one of the following:
• Use a name used by another language (that doesn’t conflict with Swift)
• Introduce a concept of removing nils in Swift and call it the same
thing (e.g. compacted)
• Have an awkward, long, and overly specific name like mapAndRemoveNils
I think it might make sense to just drop the quest for forward transfer, and
instead look for a short, readable, and memorable name that makes sense in
hindsight once you have seen it (e.g. dropMap?). That, or introduce a word
that means to remove nils.
Thanks,
Jon
> On Nov 20, 2017, at 9:22 AM, BJ Homer via swift-evolution
> <[email protected]> wrote:
>
>
>
>> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> The typical case for this function in my code is the identity closure, that
>> is
>>
>> let a: [Int?] = ...
>> print(a.filterMap {$0})
>>
>> filterMap is quite poor for this situation because *each* component in the
>> term is inaccurate:
>
> filterMap is indeed an awkward name for this use case, just like flatMap is.
> In my experience, about half of my use cases use the identity closure, and
> half actually make use of the closure in a meaningful way. I would support a
> proposal to add something like Sequence.dropNils (actual name to be
> determined), and then we could let this proposal target the
> non-identity-closure use case.
>
> -BJ
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
