<!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">On 16 Mar 2017, at 13:27, David Hart wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">> On 16 Mar 2017, at 20:55, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote:</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><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.<br>
<br>
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,<br>
<br>
func foo() -> Int { return 42 }<br>
func foo() -> Double { return .pi }<br>
func consumesInt(_ x : Int) { print(x) }<br>
<br>
let x = foo() // Ambiguous use of foo()<br>
consumesInt(x) // Even though x is going to be used as an Int<br>
let y: Int = x // Same here<br>
let x = foo() as Int 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 let x: Int = foo(). This has since been fixed, but it was very confusing to try to figure out the unambiguous way to call it.<br>
<br>
Keep in mind that this isn’t an unreasonable thing to want to do:<br>
<br>
struct Foo {<br>
var x: Int<br>
init(from decoder: Decoder) throws {<br>
let container = try decoder.container(keyedBy: CodingKeys.self)<br>
<br>
// Want to process an element before it’s assigned.<br>
let x = container.decode(forKey: .x) // Ambiguous call<br>
<br>
// Or whatever.<br>
if x < 0 {<br>
self.x = x + 100<br>
else {<br>
self.x = x * 200<br>
}<br>
}<br>
}<br>
You can write let x: Int = container.decode(…) or let x = container.decode(…) as Int, but this isn’t always intuitive.<br>
</p>
</blockquote><p dir="auto">That’s where I disagree. Let me try to prove my point:<br>
<br>
You bring up the example of having to store the decoded value in a variable before setting it to a typed property. But its also not unreasonable to want to do the same thing when encoding the value, possibly storing it into a different type. If we follow that argument, its also not very intuitive to have to do<br>
<br>
container.encode(x as Double, forKey: .x).<br>
<br>
Wouldn’t that be an argument to have an API like this:<br>
<br>
func encode<T>(_ value: Data?, forKey key: Key, as type: T.Type) throws</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I don’t agree that these are equivalent cases.</p>
<p dir="auto">Here, for an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">as</code> cast to be valid, the type of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">x</code> must be an existential (I’m guessing <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Any</code>).<br>
The original <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">container.encode(x, forKey: .x)</code> call is not ambiguous because <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">x</code> has no type, but rather because the type of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">x</code> does not match any of the overloads. You would get the same error as if you wrote</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">NonCodableFoo</span> {}
<span style="color: #008800; font-weight: bold">let</span> <span style="color: #996633">x</span> = NonCodableFoo()
container.encode(x, forKey: .x)
</code></pre>
<p dir="auto">You have to convert the type to something that fits one of the overloads.</p>
<p dir="auto">On encode, there cannot be any true ambiguity because it’s not possible to satisfy more than one of these concrete overloads. You cannot have a thing with a type which would satisfy both, say, <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int</code> and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Double</code>.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">I would argue that type inference is a core feature in Swift and that we should embrace it. I believe that in most cases the return value of encode will be stored into a typed property and type inference will do the right thing. In the few cases where the type has to be enforced, the patterns you mention above are not weird syntax; they are used and useful all over Swift:</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Sure, but I think these cases are not equivalent.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">let cgFloat: CGFloat = 42</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">42 has a default value of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int</code>, but since <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">CGFloat</code> is <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">ExpressibleByIntLiteral</code>, this becomes the equivalent of writing <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let cfFloat = CGFloat(42)</code>, which would not be ambiguous without the <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">CGFloat()</code>; you would just get an <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int</code>.</p>
<p dir="auto">With <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let x = container.decode(forKey: .x)</code>, has <em>has no type</em> unless otherwise specified.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">let pi = 3.14159265359 as Float</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Same here, but with <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Double</code> instead of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int</code>, and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Float</code> instead of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">CGFloat</code>…</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">let person = factory.get<Person>() // potential feature in Generics Manifesto</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">This isn’t type inference. This is type specification, which is exactly what we are trying to do. At the moment, explicit type specification has a different syntax: passing a metatype as an argument.</p>
<p dir="auto">If this feature were available, this is what we would use.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">The way I think about it is that the type argument is already there as a generic parameter. Adding an extra argument that needs to be explicitly given on every single call feels like unneeded verbosity to me.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">For consideration: why does <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let person = factory.get<Person>()</code> seem reasonable, but <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">let person = factory.get(Person.self)</code> does not?</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">Consider also that the metatype would also be necessary for decode<Value : Codable>(_ type: Value.Type, forKey: Key) -> Value because the return value of that certainly could be ambiguous in many cases.<br>
<br>
Finally, the metatype arg allows you to express the following succinctly: let v: SuperClass = container.decode(SubClass.self, forKey: .v).<br>
<br>
In the general case (decode<Value : Codable>) 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?"<br>
<br>
Matthew offered func decode<T>(_ key: Key, as type: T.Type = T.self) throws -> T which looks appealing, but:<br>
<br>
Doesn’t help resolve the ambiguity either<br>
Allows for 3 ways of expressing the same thing (let x: Int = decode(key), let x = decode(key) as Int, and let x = decode(key, as: Int.self))<br>
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.<br>
</p>
</blockquote><p dir="auto">Agreed. Foundation should not add API just because 3rd parties do it. But 3rd parties should not be dismissed entirely nonetheless. They are a good breeding ground for ideas to spawn and shape Swift in interesting ways.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">True. I don’t want to seem dismissive of third parties here. The limitations that we operate within are more conservative than those third parties tend to work within; we would prefer to offer consistency over concision.</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">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.<br>
<br>
On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:<br>
<br>
<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution <swift-evolution@swift.org <<a href="mailto:swift-evolution@swift.org" style="color:#BBB">mailto:swift-evolution@swift.org</a>>> wrote:<br>
<br>
On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote:</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">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>
<br>
let i = decode(.myKey) as Int</p>
</blockquote><p dir="auto">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>
<br>
Any official Swift or Foundation API shouldn't, or shouldn't need to, make use of "tricky" syntax.</p>
</blockquote><p dir="auto">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.<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">If we don’t support this in Foundation we will continue to see 3rd party libraries that do this.</p>
</blockquote><p dir="auto">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?</p>
</blockquote><p dir="auto">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.<br>
<br>
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.<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><p dir="auto">Zach Waldowski<br>
zach@waldowski.me <<a href="mailto:zach@waldowski.me" style="color:#BBB">mailto:zach@waldowski.me</a>><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
swift-evolution@swift.org <<a href="mailto:swift-evolution@swift.org" style="color:#BBB">mailto:swift-evolution@swift.org</a>><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#BBB">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</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:#999">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#999">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
_______________________________________________<br>
swift-evolution mailing list<br>
swift-evolution@swift.org<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#999">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>