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 > <swift-evolution@swift.org> wrote: > > > >> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution