<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Wed, Nov 8, 2017, at 11:28 AM, Max Moiseev wrote:<br></div>
<blockquote type="cite"><div><br></div>
<div><div><br></div>
<blockquote type="cite"><div>On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div>
<div><br></div>
<div><div><div>On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:<br></div>
<blockquote type="cite"><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;"><div><a href="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</a><br></div>
</blockquote><div><br></div>
<div><div>• What is your evaluation of the proposal?<br></div>
</div>
</blockquote><div><br></div>
<div>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></div>
<div><br></div>
<blockquote type="cite"><div><div>• Is the problem being addressed significant enough to warrant a change to Swift?<br></div>
</div>
</blockquote><div><br></div>
<div>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></div>
<div><br></div>
<div>I'd much rather see a proposal to add a new @available type, something like 'warning’,<br></div>
</div>
</div>
</blockquote><div>Please write one, seriously!<br></div>
<div><br></div>
<blockquote type="cite"><div><div><div>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<br></div>
<div><br></div>
<div>extension Sequence {<br></div>
<div>&nbsp; &nbsp; @available(*, warning: "Use map instead")<br></div>
<div>&nbsp; &nbsp; func flatMap&lt;U&gt;(_ f: (Element) -&gt; U) -&gt; [U] {<br></div>
<div>&nbsp; &nbsp; &nbsp; &nbsp; return map(f)<br></div>
<div>&nbsp; &nbsp; }<br></div>
<div>}<br></div>
</div>
</div>
</blockquote><div>FWIW: This was attempted in the past, and had to be reverted for the reason other than «deprecated» being a confusing message.<br></div>
<div><a href="https://github.com/apple/swift/pull/9390">https://github.com/apple/swift/pull/9390</a><br></div>
</div>
</blockquote><div><br></div>
<div>Interesting. It looks like what's going on is, with the deprecated form, `[a, b, c]` is immediately treated as `[Any]`, but without it, it's treated as `[Int?]` (invoking optional hoisting on `a`) and the closure itself is inferred as returning Any.<br></div>
<div><br></div>
<div>There's probably some shenanigans we could do like adding an _ImplicitlyPromotedOptional&lt;T&gt; type that takes precedence over Optional&lt;T&gt; for overloading purposes, which could then be used to reintroduce the deprecated form of flatMap, but I'm not sure if it's worth the additional complexity unless there are more functions than just flatMap that we'd want to kill optional hoisting for.<br></div>
<div><br></div>
<div>-Kevin Ballard</div>
<div><br></div>
<blockquote type="cite"><div><div><br></div>
<blockquote type="cite"><div><div><div><br></div>
<div>And now if someone writes flatMap in a way that invokes optional hoisting, it'll match this overload instead and warn them.<br></div>
<div><br></div>
<blockquote type="cite"><div><div>• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></div>
</div>
</blockquote><div><br></div>
<div>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></div>
<div><br></div>
<div>-Kevin Ballard<br></div>
<div><br></div>
</div>
<div>_______________________________________________<br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div>
</div>
</blockquote></div>
</blockquote><div><br></div>
</body>
</html>