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

Kevin Ballard kevin at sb.org
Tue Nov 7 17:34:55 CST 2017


On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md> 
> • What is your evaluation of the proposal?

This proposal is going to cause an insane amount of code churn. The
proposal suggests this overload of flatMap is used "in certain
circumstances", but in my experience it's more like 99% of all flatMaps
on sequences are to deal with optionals, not to flatten nested
sequences.
> • Is the problem being addressed significant enough to warrant a
> change to Swift?
I don't think so. It's a fairly minor issue, one that really only
affects new Swift programmers anyway rather than all users, and it will
cause far too much code churn to be worthwhile.
I'd much rather see a proposal to add a new @available type, something
like 'warning', that lets you attach an arbitrary warning message to a
call (which you can kind of do with 'deprecated' except that makes the
warning message claim the API is deprecated). With that sort of thing we
could then declare
extension Sequence {
    @available(*, warning: "Use map instead")
    func flatMap<U>(_ f: (Element) -> U) -> [U] {
        return map(f)
    }
}

And now if someone writes flatMap in a way that invokes optional
hoisting, it'll match this overload instead and warn them.
> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
A quick reading, and a couple of minutes testing overload behavior with
availability attributes (to confirm that we can't simply use
'unavailable' for this).
-Kevin Ballard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171107/4e68b129/attachment.html>


More information about the swift-evolution mailing list