> On Nov 7, 2017, at 6: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', 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).
As review manager, I generally try to avoid commenting on threads, but I find
this point interesting in a way that, if you don't mind, I'd like to explore.
Would this attribute not be a form of deprecation? Certainly it acts to
discourage current and subsequent use, since every such use will evoke a
warning.
Is the word "deprecation" just too strong? Often we think of deprecated APIs
as being ones with more functional problems, like an inability to report
errors, or semantics that must have seemed like a good idea at the time. Here
it's just that the API has a name we don't like, and perhaps "deprecation"
feels unnecessarily judgmental.
Also, more practically, it conflates a relatively unimportant suggestion — that
we should call the new method in order to make our code clearer — with a more
serious one — that we should revise our code to stop using a problematic API.
Yes, the rename has a fix-it, but still: to the extent that these things demand
limited attention from the programmer, that attention should clearly be focused
on the latter set of problems. Perhaps that sense of severity is something
that an IDE should take into consideration when reporting problems.
What else would you have in mind for this warning?
John.
> 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
>
> _______________________________________________
> 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
