<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 Karl,<div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 22, 2017, at 6:23 AM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 20 Apr 2017, at 19:08, 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="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi everyone,<div class=""><br class=""></div><div class="">Thanks for your feedback on this proposal. Based on that plus additional feedback from core team members and others who responded off-thread, we are making the following small adjustments:</div><div class=""><br class=""></div><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><div class="">* 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 class="">* JSONEncoder/Decoder, PropertyListEncoder/Decoder remain in Foundation. These are concrete implementations of the above protocols, like the ones that will appear in many libraries, we hope.</div><div class=""><br class=""></div><div class="">We are not currently proposing using the integer protocols. The reasoning is that using them them confers a requirement upon all possible encoders and decoders to support arbitrary-width integers and floating point values. We’re not convinced this is feasible, but we will continue to evaluate.</div><div class=""><br class=""></div><div class="">If the core team accepts the modified proposal, we will get this merged as soon as possible with the goal of allowing all of you to try everything out via Swift’s frequent toolchain snapshots. We will be looking for feedback on how it works in more real world scenarios, and we will consider further adjustments to the API before Swift 4 is final. We are hoping that this extended trial period will allow us to make sure that everything works out the way we expected.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Tony</div></div></div></blockquote></div><br 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;"><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;"><br class=""></div><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;">That’s a great step; thanks a lot!</div><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;"><br class=""></div><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;">As for Data/UnsafeRawBufferPointer (beyond this proposal): I agree that a Data object which owns its buffer should be the common-currency for passing buffers around, but I also think that the standard library should own that “Data” type. Data is (IMO), no less "primitive” than, say, Array, Dictionary, Set and String - yet while all of those types are part of the standard library, Data lives much further down the stack, in Foundation. The standard library is limited to unsafe buffers, without a “safe” alternative. Even though Foundation is a core library and very useful, it is still an <i class="">optional</i> component of any Swift installation or application, and I feel it’s not unreasonable to ask for a safe buffer without that dependency.</div><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;"><br class=""></div><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;">I could of course define my own RAII, UnsafeRawBufferPointer-wrapping “Data” type, but then it either spreads throughout my API and undermines Data as a common currency, or I need to convert it (with a copy, in order to preserve value semantics). This is the same issue that affects DispatchData/Data bridging, which in that case undermines APIs such as DispatchIO; either all of my APIs now take a DispatchData (leaking implementation details), or I have to copy the buffer in to a Foundation Data.</div><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;"><br class=""></div></div></blockquote><div><br class=""></div>We’re aware of this, but it’s something I’d like to tackle separately from the Coding proposals.</div><div><br class=""><blockquote type="cite" class=""><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;">That’s an issue which I would like to help solve more comprehensively one day, but for the mean time:</div><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;"><br class=""></div><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;">1) Is untyped data really a “primitive” in the context of serialisation? If so...</div><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;">2) Why are we removing it? Is it only because the standard library lacks a good type to represent the data? If so...</div><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;">3) Why not introduce a generic function?</div><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;"><br class=""></div><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;">mutating func encodeBytes<C>(_ bytes: C, forKey key: Key) throws where C: Collection, C.Element == UInt8</div><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;"><br class=""></div><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;">This single function would be able to encode Data, DispatchData, UnsafeRawBufferPointer, and even an Array<UInt8>.</div><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;"><br class=""></div><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;">- Karl</div></div></blockquote></div><br class=""></div><div class="">We considered something along these lines:</div><div class=""><br class=""></div><div class=""> func encode<T : Encodable>(_ value: T?, ...) // existing<br class=""> func encode<T : RangeRepleaceableCollection>(_ value: T?, ...) where T.Iterator.Element == UInt8<br class=""><br class=""></div><div class="">but this is ambiguous when we have conditional conformance and Array where Element : Encodable is Encodable. Did you mean to encode base64-encoded data for JSON or an array of UInt8? Data resolves the ambiguity by assigning more meaning to a Collection of UInt8.</div><div class=""><br class=""></div><div class="">We could resolve the ambiguity by using a different name (like you suggest above), but this reduces the viability of Data as a common currency type, which we believe is very important. Ultimately we felt that going with one less primitive here was a better approach.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""></div></body></html>