<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">The idea is that renaming this will nudge people into using map when appropriate.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 9, 2017, at 1:45 PM, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">- 1 I agree with Kevin Ballard. <div class=""><br class=""></div><div class="">I think that it would be appropriate to nudge the user to use map instead. </div><div class=""><br class=""></div><div class="">We already nudge people to use let over var so I think is sensible to do the same for misuses of flatMap when map is sufficient.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 10:43 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 8, 2017, at 1:20 PM, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote:<br class=""></div>
<blockquote type="cite" class=""><div class=""><br class=""></div>
<div class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div>
<div class=""><br class=""></div>
<div class=""><div class=""><div class="">On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:40px;border-top-width:initial;border-right-width:initial;border-bottom-width:initial;border-left-width:initial;border-top-style:none;border-right-style:none;border-bottom-style:none;border-left-style:none;border-top-color:initial;border-right-color:initial;border-bottom-color:initial;border-left-color:initial;border-image-source:initial;border-image-slice:initial;border-image-width:initial;border-image-outset:initial;border-image-repeat:initial;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;" class=""><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md</a><br class=""></div>
</blockquote><div class=""><br class=""></div>
<div class=""><div class="">• What is your evaluation of the proposal?<br class=""></div>
</div>
</blockquote><div class=""><br class=""></div>
<div class="">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.<br class=""></div>
<div class=""><br class=""></div>
<blockquote type="cite" class=""><div class=""><div class="">• Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div>
</div>
</blockquote><div class=""><br class=""></div>
<div class="">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.<br class=""></div>
<div class=""><br class=""></div>
<div class="">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).<br class=""></div>
</div>
</div>
</blockquote><div class=""><br class=""></div>
<div class="">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.<br class=""></div>
</div>
<div class=""><br class=""></div>
<div class="">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.<br class=""></div>
<div class=""><br class=""></div>
<div class="">Is the word "deprecation" just too strong? Often we think of deprecated APIs as being ones with more <i class="">functional</i> 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.<br class=""></div>
</blockquote><div class=""><br class=""></div>
<div class="">What I'm suggesting is that we don't change the API name at all. That's why I don't want to use 'deprecated', because we're not actually deprecating something. I'm just suggesting an alternative way of flagging cases where the user tries to use flatMap but accidentally invokes optional hoisting, and that's by making a new overload of flatMap that works for non-optional (non-sequence) values and warns the user that what they're doing is better done as a map. Using the 'deprecated' attribute for this would be confusing because it would make it sound like flatMap itself is deprecated when it's not.</div></div></div></blockquote><div class=""><br class=""></div>I see. Thanks.</div><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<div class=""><br class=""></div>
<blockquote type="cite" class=""><div class="">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.<br class=""></div>
<div class=""><br class=""></div>
<div class="">What else would you have in mind for this warning?<br class=""></div>
</blockquote><div class=""><br class=""></div>
<div class="">The main use for this warning would be for adding overloads to methods that take optionals in order to catch the cases where people invoke optional hoisting, so we can tell them that there's a better way to handle it if they don't have an optional. flatMap vs map is the obvious example, but I'm sure there are other cases where we can do this too.<br class=""></div>
<div class=""><br class=""></div>
<div class="">But there are also other once-off uses. For example, in the past I've written a function that should only ever be used for debugging, so I marked it as deprecated with a message saying 'remove this before committing your code'. This warning would have been better done using the new 'warning' attribute instead of as a deprecation notice.<br class=""></div>
<div class=""><br class=""></div>
<div class="">-Kevin Ballard</div>
<div class=""><br class=""></div>
<blockquote type="cite" class=""><div class=""><div class="">John.<br class=""></div>
<div class=""><br class=""></div>
<blockquote type="cite" class=""><div class=""><div class=""><div class="">With that sort of thing we could then declare<br class=""></div>
<div class=""><br class=""></div>
<div class="">extension Sequence {<br class=""></div>
<div class=""> @available(*, warning: "Use map instead")<br class=""></div>
<div class=""> func flatMap<U>(_ f: (Element) -> U) -> [U] {<br class=""></div>
<div class=""> return map(f)<br class=""></div>
<div class=""> }<br class=""></div>
<div class="">}<br class=""></div>
<div class=""><br class=""></div>
<div class="">And now if someone writes flatMap in a way that invokes optional hoisting, it'll match this overload instead and warn them.<br class=""></div>
<div class=""><br class=""></div>
<blockquote type="cite" class=""><div class=""><div class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div>
</div>
</blockquote><div class=""><br class=""></div>
<div class="">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).<br class=""></div>
<div class=""><br class=""></div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""><br class=""></div>
</div>
<div class="">_______________________________________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</blockquote></div>
</blockquote><div class=""><br class=""></div>
</div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>