<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><blockquote type="cite" class=""><div class="">On Mar 19, 2017, at 12:21 PM, Tony Parker &lt;<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>&gt; wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Mar 19, 2017, at 12:14 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class=""><div class="">On Mar 19, 2017, at 10:47 AM, Tony Parker &lt;<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>&gt; wrote:</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="">Hi Matthew, Brent,<div class=""><br class=""></div><div class="">I see why you are asking for this Context parameter, but putting it into the basic Codable protocol introduces too much conceptual overhead. There are too many benefits to keeping adoption to just one protocol, including discoverability, ease of use, reducing the need for overloads on protocols elsewhere, and more. Supporting this one use case does not outweigh those benefits, especially considering I expect that most library code would not use it (as you say: it would be weird to pass this context between modules).</div><div class=""><br class=""></div><div class="">Can you figure out a way to get the context info passed through the encoder/decoder instead? It would make more sense as something optionally retrieved from the encoder/decoder that was set at the top level.</div></div></blockquote><div class=""><br class=""></div><div class="">Hi Tony. &nbsp;<span class="" style="background-color: rgba(255, 255, 255, 0);">I can see the argument that the this is a feature that should be relatively rarely used and thus should have as simple a design as possible.</span></div><div class=""><br class=""></div><div class="">If you feel like the impact of threading a typed context on the API surface area is too heavy you could just add a `var context: Any? { get }` requirement to Encoder and Decoder. &nbsp;The expectation is that encoders and decoders would accept a context in the top level call and make it available to all Codable types. &nbsp;This would solve the problem with minimal API impact at the cost of the ability to statically verify that all types receive the context they need to encode / decode correctly.</div><div class=""><br class=""></div><div class="">I much prefer the static safety but having a solution is better than not having one. &nbsp;:)</div></div></div></blockquote><div class=""><br class=""></div>The Any context property is reasonable, but it would be nice to find something in the middle. =)</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">One other possibility is that we define a user info dictionary instead, with a custom key type that can be extended (much like our string enumerations). In general I haven’t been a fan of the user info pattern in Swift because of the necessity to cast, but as you say it’s better than nothing. e.g. userInfo : [CodingUserInfoKey: Any].</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></blockquote><br class=""></div><div>I hate casting out of Any, and I strongly believe we should support multiple contexts, so personally, I'd prefer something typed:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>protocol Encoder {</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>// Retrieve the context instance of the indicated type.</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>func context&lt;Context&gt;(ofType type: Context.Type) -&gt; Context?</div><div><span class="Apple-tab-span" style="white-space:pre">                </span></div><div><span class="Apple-tab-span" style="white-space:pre">                </span>// This context is visible for `encode(_:)` calls from this encoder's containers all the way down, recursively.</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>func addContext&lt;Context&gt;(_ context: Context, ofType type: Context.Type)</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>// Likewise on Decoder</div><div><span class="Apple-tab-span" style="white-space:pre">        </span></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>// Encoder and decoder classes should accept contexts in their top-level API:</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>open class JSONEncoder {</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>open&nbsp;func&nbsp;encode&lt;Value&nbsp;:&nbsp;Codable&gt;(_&nbsp;value:&nbsp;Value, withContexts contexts: [Any] = [])&nbsp;throws&nbsp;-&gt;&nbsp;Data</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">--&nbsp;</div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>

</div>
<br class=""></body></html>