<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=""><br class=""><div><blockquote type="cite" class=""><div class="">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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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=""><div class=""><br class=""></div><div class="">That’s a great step; thanks a lot!</div><div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">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=""><br class=""></div><div class="">That’s an issue which I would like to help solve more comprehensively one day, but for the mean time:</div><div class=""><br class=""></div><div class="">1) Is untyped data really a “primitive” in the context of serialisation? If so...</div><div class="">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="">3) Why not introduce a generic function?</div><div class=""><br class=""></div><div class="">mutating func encodeBytes<C>(_ bytes: C, forKey key: Key) throws where C: Collection, C.Element == UInt8</div><div class=""><br class=""></div><div class="">This single function would be able to encode Data, DispatchData, UnsafeRawBufferPointer, and even an Array<UInt8>.</div><div class=""><br class=""></div><div class="">- Karl</div></body></html>