<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">I’m going to reply to this thread as a whole — apologies if there’s someone’s comment that I’ve missed.</p>
<p dir="auto">This is something that has come up in internal review, and we’ve certainly given it thought. As Zach has already mentioned, the primary concern with overloading based on return type is ambiguity.<br>
There are many cases in which Swift’s type system currently does not handle ambiguity in the way that you would expect, and it can be very surprising. For instance,</p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px; color:black" bgcolor="#F7F7F7"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7"><span style="color: #008800; font-weight: bold">func</span> <span style="color: #0066BB; font-weight: bold">foo</span>() -> <span style="color: #007020">Int</span> { <span style="color: #008800; font-weight: bold">return</span> <span style="color: #0000DD; font-weight: bold">42</span> }
<span style="color: #008800; font-weight: bold">func</span> <span style="color: #0066BB; font-weight: bold">foo</span>() -> <span style="color: #007020">Double</span> { <span style="color: #008800; font-weight: bold">return</span> .pi }
<span style="color: #008800; font-weight: bold">func</span> <span style="color: #0066BB; font-weight: bold">consumesInt</span>(<span style="color: #008800; font-weight: bold">_</span> x : <span style="color: #007020">Int</span>) { <span style="color: #007020">print</span>(x) }
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">x</span> = foo() <span style="color: #888888">// Ambiguous use of foo()</span>
consumesInt(x) <span style="color: #888888">// Even though x is going to be used as an Int</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">y</span>: <span style="color: #007020">Int</span> = x <span style="color: #888888">// Same here</span>
</code></pre>
<p dir="auto"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x = foo() as Int</code> works now, but it actually didn’t always — until a somewhat recent version of Swift AFAICT, the only way to resolve the ambiguity was through <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x: Int = foo()</code>. This has since been fixed, but it was very confusing to try to figure out the unambiguous way to call it.</p>
<p dir="auto">Keep in mind that this isn’t an unreasonable thing to want to do:</p>
<pre style="background-color:#F7F7F7; border-radius:5px 5px 5px 5px; margin-left:15px; margin-right:15px; max-width:90vw; overflow-x:auto; padding:5px; color:black" bgcolor="#F7F7F7"><code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0" bgcolor="#F7F7F7"><span style="color: #008800; font-weight: bold">struct</span> <span style="color: #BB0066; font-weight: bold">Foo</span> {
<span style="color: #008800; font-weight: bold">var</span> <span style="color: #996633">x</span>: <span style="color: #007020">Int</span>
<span style="color: #008800; font-weight: bold">init</span>(from decoder: Decoder) throws {
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">container</span> = try decoder.container(keyedBy: CodingKeys.<span style="color: #008800; font-weight: bold">self</span>)
<span style="color: #888888">// Want to process an element before it’s assigned.</span>
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">x</span> = container.decode(forKey: .x) <span style="color: #888888">// Ambiguous call</span>
<span style="color: #888888">// Or whatever.</span>
<span style="color: #008800; font-weight: bold">if</span> x <span style="color: #333333"><</span> <span style="color: #0000DD; font-weight: bold">0</span> {
<span style="color: #008800; font-weight: bold">self</span>.x = x <span style="color: #333333">+</span> <span style="color: #0000DD; font-weight: bold">100</span>
<span style="color: #008800; font-weight: bold">else</span> {
<span style="color: #008800; font-weight: bold">self</span>.x = x <span style="color: #333333">*</span> <span style="color: #0000DD; font-weight: bold">200</span>
}
}
}
</code></pre>
<p dir="auto">You can write <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x: Int = container.decode(…)</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x = container.decode(…) as Int</code>, but this isn’t always intuitive.<br>
Consider also that the metatype would also be necessary for <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">decode<Value : Codable>(_ type: Value.Type, forKey: Key) -> Value</code> because the return value of that certainly could be ambiguous in many cases.</p>
<p dir="auto">Finally, the metatype arg allows you to express the following succinctly: <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let v: SuperClass = container.decode(SubClass.self, forKey: .v)</code>.</p>
<p dir="auto">In the general case (<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">decode<Value : Codable></code>) we would need the metatype to avoid ambiguity. It’s not strictly necessary for primitive types, but helps in the case of ambiguity, and solves the conceptual overhead of "Why do I specify the type sometimes but not others? Why are some of these types special? Should I always provide the type? Why wouldn’t I?"</p>
<p dir="auto">Matthew offered <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">func decode<T>(_ key: Key, as type: T.Type = T.self) throws -> T</code> which looks appealing, but:</p>
<ol>
<li value="1">Doesn’t help resolve the ambiguity either</li>
<li value="2">Allows for 3 ways of expressing the same thing (<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x: Int = decode(key)</code>, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x = decode(key) as Int</code>, and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x = decode(key, as: Int.self)</code>)</li>
</ol>
<p dir="auto">The cognitive overhead of figuring out all of the ambiguity goes away when we’re consistent everywhere.<br>
FWIW, too, I am not convinced that Foundation should add API just because 3rd parties will add it. The ambiguity in the general case cannot be solved by wrappers, and I would prefer to provide one simple, consistent solution; if 3rd parties would like to add wrappers for their own sake, then I certainly encourage that.</p>
<p dir="auto">On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:normal"></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><div id="42F7084E-4D77-4CB6-A834-C0F0E70F1875"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2017, at 1:34 PM, Zach Waldowski 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="">
<title class=""></title>
<div class=""><div style="font-family:Arial;" class="">On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div style="font-family:Arial;" class="">I don’t have an example but I don’t see a problem either. There are two options for specifying the return type manually. We can use the signature you used above and use `as` to specify the expected type:<br class=""></div>
<div class=""><div class=""><br class=""></div>
<div class="">let i = decode(.myKey) as Int<br class=""></div>
</div>
</blockquote><div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">The awkwardness of this syntax is exactly what I'm referring to. Would a beginner know to use "as Int" or ": Int"? Why would they? The "prettiness" of the simple case doesn't make up for how difficult it is to understand and fix its failure cases.<br class=""></div>
<div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">Any official Swift or Foundation API shouldn't, or shouldn't need to, make use of "tricky" syntax.<br class=""></div></div></div></blockquote><div><br class=""></div><div>I don’t think this is especially tricky. Nevertheless, we can avoid requiring this syntax by moving the type argument to the end and providing a default. But I think return type inference is worth supporting. It has become widely adopted by the community already in this use case.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<div style="font-family:Arial;" class=""><br class=""></div>
<blockquote type="cite" class=""><div class=""><div class="">If we don’t support this in Foundation we will continue to see 3rd party libraries that do this.<br class=""></div>
</div>
</blockquote><div style="font-family:Arial;" class=""><br class=""></div>
<div style="font-family:Arial;" class="">The proposal's been out for less than 24 hours, is it really productive to already be taking our ball and go home over such a minor thing?<br class=""></div></div></div></blockquote><div><br class=""></div><div>I don’t think that’s what I’m doing at all. This is a fantastic proposal. I’m still working through it and writing up my more detailed thoughts.</div><div><br class=""></div><div>That said, as with many (most?) first drafts, there is room for improvement. I think it’s worth pointing out the syntax that many of us would like to use for decoding and at least considering including it in the proposal. If the answer is that it’s trivial for those who want to use subscripts to write the wrappers for return type inference and / or subscripts themselves that’s ok. But it’s a fair topic for discussion and should at least be addressed as an alternative that was rejected for a specific reason.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<div style="font-family:Arial;" class=""><div style="font-family:Arial;" class=""><div style="font-family:Arial;" class=""><br class=""></div>
</div>
<div style="font-family:Arial;" class=""><div style="font-family:Arial;" class=""><span class="font" style="font-family:arial, sans-serif, sans-serif">Zach Waldowski</span><br class=""></div>
</div>
<div id="sig40804545" class=""><div class="signature"><a href="mailto:zach@waldowski.me" class=""><span class="font" style="font-family:arial, sans-serif, sans-serif">zach@waldowski.me</span></a><br class=""></div>
</div>
<div class=""><div style="font-family:Arial;" class=""><br class=""></div>
</div>
<div class=""><div style="font-family:Arial;" class=""><br class=""></div>
</div>
<div class=""><div style="font-family:Arial;" class=""><br class=""></div>
</div>
</div>
<div style="font-family:Arial;" class=""><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=""></div></div></blockquote>
<div style="white-space:normal">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px">
</blockquote><p dir="auto">_______________________________________________<br>
swift-evolution mailing list<br>
swift-evolution@swift.org<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#3983C4">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>