> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 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
>>  
>> <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’,
Please write one, seriously!

> 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)
>     }
> }
FWIW: This was attempted in the past, and had to be reverted for the reason 
other than «deprecated» being a confusing message.
https://github.com/apple/swift/pull/9390 
<https://github.com/apple/swift/pull/9390>


> 
> 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
> 
> _______________________________________________
> 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

Reply via email to