[swift-evolution] [swift-evolution-announce] [Review] SE-0166: Swift Archival & Serialization
brent at architechies.com
Fri Apr 21 01:37:48 CDT 2017
> On Apr 20, 2017, at 10:08 AM, Tony Parker via swift-evolution <swift-evolution at swift.org> wrote:
> * 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.
I think this is a huge win for Swift and a great move, but...
> * 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.
...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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution