<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Nov 2017, at 6:24 am, Tony Parker 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=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Florent,<div class=""><br class=""></div><div class="">We definitely thought about this while designing the set of types with the Codable proposals.</div><div class=""><br class=""></div><div class="">One serious concern was just how much API surface area there already is with Codable. If we open up the internal classes as well, we risk confusing the majority of people who are just adopting Codable with APIs that are intended only for the minority of people who are trying to create their own custom encoders and decoders.</div><div class=""><br class=""></div><div class="">Any thoughts on how to mitigate this?</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- Tony<br class=""></div></div></div></blockquote><div><br class=""></div><div>I’ve been curious for some time about if we can do something about an opt-in import in Swift?</div><div><br class=""></div><div>For example, currently UIGestureRecognizer in UIKit has “subclass only” methods that are protected and opt in. Importing UIKit itself doesn’t bring it in, and instead you need to specifically import UIKit.UIGestureRecognizerSubclass.</div><div><br class=""></div><div>I realise this is a standalone case, but I’m wondering whether we can generalise this into something we can propose, to actively support nested scopes in the same way?</div><div><br class=""></div><div>This would lend well to disclosing the internals like this. It would avoid users jumping straight for the internal types because they wouldn’t be there with “import Foundation” - it would require something eg “import <a href="http://Foundation.xyz" class="">Foundation.xyz</a>”.</div><div><br class=""></div><div>Was this part of an earlier discussion of modules etc?</div><div><br class=""></div><div>- Rod</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 3, 2017, at 9:58 AM, Florent Vilmart 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 name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class="">
<div class="">At Swift Summit, we discussed with Joe and Jordan about opening up the Encoder/Decoder classes in order to make the work of an encoder designer easier.</div>
<div class=""><br class=""></div>
<div class="">As I was working on an API project, I found myself into the situation of needing to tweak so slightly the encoding strategy this required a full copy/paste of the JSONEncoder.swift file and playing with the internals. I also wanted to implement a simple QueryStringEncoder/Decoder that would properly encode / decode a query string.</div>
<div class=""><br class=""></div>
<div class="">The internally defined classes are proven a very powerful tool of reflection as well, being able to collect / untransform a series of containers safely into a strongly typed swift object.</div>
<div class=""><br class=""></div>
<div class="">The pitch:</div>
<div class=""><br class=""></div>
<div class="">- Keep JSONEncoder / JSONDecoder as 'proxies' to encoding to Data</div>
<div class="">- Make _JSONEncoder / _JSONDecoder open classes</div>
<div class="">- Mark public all container implementations of UnkeyedEncodingContainers etc... </div>
<div class="">- Find a good naming for the _JSONEncoder and _JSONDecoder, that doesn't conflict with JSONEncoder / JSONDecoder but also denotes they conform to Encoder. </div>
<div class=""><br class=""></div>
<div class="">Opening those API's isn't for the general Codable implementation, the JSONEncoder/JSONDecoder should stay as-is but it's intended to reduce the amount of boiler plate one would need to implement in order to provide different serialization mechanism / strategy.</div>
<div class=""> </div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;" class=""><br class="">
<div class=""></div>
</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>_______________________________________________<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>