<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">One point of concern with making the implementations rely on that: it would require any adopter of Codable to be built in swift 4 mode no? it might be valuable to keep the protocol not requiring Swift 4 to aide in incremental migration.</div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2017, at 2:14 PM, Matthew Johnson 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 Mar 16, 2017, at 4:12 PM, Itai Ferber <<a href="mailto:iferber@apple.com" class="">iferber@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">If throwing subscripts made it in the Swift 4 timeframe, then we would certainly consider it.</p></div></div></div></div></blockquote><div class="">Cool. Any comment from the core team on whether this is a possibility? If it is and nobody else wants to write a proposal I would be willing to do it.</div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">On 16 Mar 2017, at 13:19, Matthew Johnson wrote:</p>
</div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><div id="1425E752-F96A-431C-AECA-8B4FCA0ADE22" 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 Mar 16, 2017, at 3:01 PM, Itai Ferber <<a href="mailto:iferber@apple.com" class="">iferber@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class="">
<div class="">
<div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">Subscripts, by the way, would not help here, since they cannot throw. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7" class="">decode</code> must be able to throw.<br class="">
<a href="https://bugs.swift.org/browse/SR-238?jql=text%20%7E%20%22subscript%20throw%22" style="color:#3983C4" class="">SR-238</a>; for Apple folks, 28775436.</p></div></div></div></div></blockquote><div class="">They don’t “help” but they do provide a more natural interface. If the Foundation team feels a more wordy interface is necessary that is ok.</div><div class=""><br class=""></div><div class="">I specifically mentioned that they can’t throw yet. Throwing subscripts would make a good companion proposal if they could fit into the Swift 4 timeframe. If not, then yes we need a method rather than a subscript. But if we can get throwing subscripts into Swift 4, why not use Swift’s first class syntactic support for keyed access to keyed containers?</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:</p><div class=""><br class="webkit-block-placeholder"></div></div>
<div style="white-space:normal" class=""></div>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class=""><div id="5E490381-6C14-4BC1-91C2-6E06CCF0642F" 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 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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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=""><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></blockquote>
<div style="white-space:normal" class="">
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class="">
</blockquote><p dir="auto" class="">_______________________________________________<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" style="color:#3983C4" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</div>
<div style="white-space:normal" class="">
</div>
</div>
</div>
</div></blockquote></div><br class=""></div></div></blockquote>
<div style="white-space:normal" class=""><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px" class="">
</blockquote></div>
</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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>