<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="">Hi Brent,<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 11:37 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</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; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 20, 2017, at 10:08 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=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">* The above will allow those protocols, plus Encodable, Decodable, typealias Codable, Encoder, Decoder, CodingKey, struct CodingUserInfoKey to be part of the standard library (not in Foundation), resolving the concern about reaching too far up the stack for the compiler.</div></div></blockquote><br class=""></div><div class="">I think this is a huge win for Swift and a great move, but...</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">* KeyedEncoderContainerProtocol, KeyedDecodingContainerProtocol, UnkeyedEncodingContainer, UnkeyedDecodingContainer, SingleValueEncodingContainer, SingleValueDecodingContainer will drop their Data-taking functions. Data will conform to Codable, so it just goes through the normal paths like other types.</div></blockquote></div><div class=""><br class=""></div><div class="">...I hope the `Data`-taking primitive will not be deleted, but rather replaced by one that takes `UnsafeRawBufferPointer` or some similar standard library representation of a byte sequence. Even if it has to be called `encodeBytes` and `decodeBytes` to clarify that it's not somehow coding a pointer, I think a series of bytes truly *is* a primitive type, and something fairly distinct from an unkeyed container of `UInt8`s.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></div></blockquote></div><br class=""></div><div class="">We still believe the right representation for the majority of data use cases is Data. UnsafeRawBufferPointer is not really the same thing, because (a) it’s unsafe, and (b) it has different mutation characteristics than CoW Data. In any case, this change encourages each encoder to decide for itself how to handle specific types if they make sense for that format. For example, JSONEncoder will switch on the type of the Encodable thing passed to it and do something different if it’s Data. It puts Data in the same bucket as things like Date and URL as types that some coders may just want to treat specially.</div><div class=""><br class=""></div><div class="">It may be reasonable for the *BufferPointer APIs to adopt Codable themselves now. They could encode themselves as [UInt8] by default. Concrete encoders (like JSONEncoder) could switch on the type to do something special if they want, like base64 encoding them. We could easily propose that as an addition to this if we think it’s valuable.</div><div class=""><br class=""></div><div class="">One more thing, which we realized after I sent my original email: the default implementation of many of the protocols needs to throw errors. Therefore we will add enum EncodingError and enum DecodingError to the list of new types. Those enums will have various associated values according to what is useful debug information. To preserve the ability for developers to present these errors to users with localized and user-presentable messages, when these enums are cast to NSError (e as? NSError), they will have the Cocoa error domain and a Foundation-provided code. (This is done via an extension to the enum in Foundation).</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""></div></body></html>