<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Hi Will,</p>
<p dir="auto">Thanks for your comments!<br>
<code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">deferredToDate</code> simply uses the default implementation that <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code> provides — since it is not a primitive type like <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Int</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">String</code> and conforms to <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Codable</code> itself, it will have an implementation of <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">init(from:)</code> and <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">encode(to:)</code>. It will have an implementation that makes sense for <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code> in general, but since a big use-case for JSON lies in talking to external servers which you don't control, allowing for custom date formatting is important.</p>
<p dir="auto">To that end, although ISO 8601 may make sense for some applications as the default, it is less efficient to format, encode, decode, and parse than, say, writing out a UNIX timestamp as a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Double</code> (or similar). Thus, the default is to allow <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code> to pick a representation that best suits itself, and if you need customization, you have the option to use it.</p>
<p dir="auto">Since <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Date</code> makes a concrete decision about how to encode, both sides will need to use <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">deferredToDate</code> for compatibility, in the same way that they would have to agree about ISO 8601, or any of the other options.</p>
<p dir="auto">HTH!</p>
<p dir="auto">— Itai</p>
<p dir="auto">P.S. About Xcode autocompletion slowdown, I don't know to be honest, but I can't imagine it would be significant. Only certain types have <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">enc...</code> or <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">dec...</code> and even then, the list of methods isn't <em>that</em> long.</p>
<p dir="auto">On 15 Mar 2017, at 18:44, Will Stanton wrote:</p>
<p dir="auto"></p></div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hello,<br>
<br>
+1<br>
<br>
This proposal seems helpful in standardizing how JSON objects can be written, and I commonly encode+decode JSON. The standard library JSON and PLIST encoders of Python are a strength, and Swift should be able to handle both formats just as easily. Still reading 'Swift Archival & Serialization’, but I believe both proposals will improve the safety and saneness of serializing/deserialization.<br>
<br>
For the JSON coder, how does `deferredToDate` work? Would both the writer and reader have to agree to use `deferredToDate`?<br>
Might it be better to force clients to pick a ‘real’ strategy? Why not default to one of the formats, perhaps ISO-8601?<br>
<br>
(Not too important but also curious how much of a slowdown there will be when Xcode/SourceKit tries to autocomplete ‘enc’ or ‘dec’ for the Swift Archival & Serialization proposal?)<br>
<br>
Regards,<br>
Will Stanton<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On Mar 15, 2017, at 6:43 PM, Itai Ferber via swift-evolution <swift-evolution@swift.org> wrote:<br>
<br>
Hi everyone,<br>
This is a companion proposal to the Foundation Swift Archival & Serialization API. This introduces new encoders and decoders to be used as part of this system.<br>
The proposal is available online and inlined below.<br>
<br>
— Itai<br>
<br>
Swift Encoders<br>
• Proposal: SE-NNNN<br>
• Author(s): Itai Ferber, Michael LeHew, Tony Parker<br>
• Review Manager: TBD<br>
• Status: Awaiting review<br>
• Associated PRs:<br>
• #8124<br>
Introduction<br>
As part of the proposal for a Swift archival and serialization API (SE-NNNN), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new Codable types in NSKeyedArchiver and NSKeyedUnarchiver.<br>
<br>
This proposal composes the latter two stages laid out in SE-NNNN.<br>
<br>
Motivation<br>
With the base API discussed in SE-NNNN, we want to provide new encoders for consumers of this API, as well as provide a consistent story for bridging this new API with our existing NSCoding implementations. We would like to offer a base level of support that users can depend on, and set a pattern that third parties can follow in implementing and extending their own encoders.<br>
<br>
Proposed solution<br>
We will:<br>
<br>
• Add two new encoders and decoders to support encoding Swift value trees in JSON and property list formats<br>
• Add support for passing Codable Swift values to NSKeyedArchiver and NSKeyedUnarchiver, and add Codable conformance to our Swift value types<br>
Detailed design<br>
New Encoders and Decoders<br>
<br>
JSON<br>
<br>
One of the key motivations for the introduction of this API was to allow safer interaction between Swift values and their JSON representations. For values which are Codable, users can encode to and decode from JSON with JSONEncoder and JSONDecoder:<br>
<br>
open class JSONEncoder {<br>
<br>
<br>
// MARK: Top-Level Encoding<br>
<br>
<br>
<br>
/// Encodes the given top-level value and returns its JSON representation.<br>
<br>
<br>
///<br>
<br>
<br>
/// - parameter value: The value to encode.<br>
<br>
<br>
/// - returns: A new `Data` value containing the encoded JSON data.<br>
<br>
<br>
/// - throws: `CocoaError.coderInvalidValue` if a non-comforming floating-point value is encountered during archiving, and the encoding strategy is `.throw`.<br>
<br>
<br>
/// - throws: An error if any value throws an error during encoding.<br>
<br>
open<br>
func encode<Value : Codable>(_ value: Value) throws -> Data<br>
<br>
<br>
<br>
// MARK: Customization<br>
<br>
<br>
<br>
/// The formatting of the output JSON data.<br>
<br>
<br>
public enum OutputFormatting {<br>
<br>
<br>
/// Produce JSON compacted by removing whitespace. This is the default formatting.<br>
<br>
<br>
case<br>
compact<br>
<br>
<br>
/// Produce human-readable JSON with indented output.<br>
<br>
<br>
case<br>
prettyPrinted<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use for encoding `Date` values.<br>
<br>
<br>
public enum DateEncodingStrategy {<br>
<br>
<br>
/// Defer to `Date` for choosing an encoding. This is the default strategy.<br>
<br>
<br>
case<br>
deferredToDate<br>
<br>
<br>
/// Encode the `Date` as a UNIX timestamp (as a JSON number).<br>
<br>
<br>
case<br>
secondsSince1970<br>
<br>
<br>
/// Encode the `Date` as UNIX millisecond timestamp (as a JSON number).<br>
<br>
<br>
case<br>
millisecondsSince1970<br>
<br>
<br>
/// Encode the `Date` as an ISO-8601-formatted string (in RFC 3339 format).<br>
<br>
@<br>
available(OSX 10.12, iOS 10.0, watchOS 3.0, tvOS 10.0, *)<br>
<br>
<br>
case<br>
iso8601<br>
<br>
<br>
/// Encode the `Date` as a string formatted by the given formatter.<br>
<br>
<br>
case formatted(DateFormatter)<br>
<br>
<br>
<br>
/// Encode the `Date` as a custom value encoded by the given closure.<br>
<br>
<br>
///<br>
<br>
<br>
/// If the closure fails to encode a value into the given encoder, the encoder will encode an empty `.default` container in its place.<br>
<br>
<br>
case custom((_ value: Date, _ encoder: Encoder) throws -> Void)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use for encoding `Data` values.<br>
<br>
<br>
public enum DataEncodingStrategy {<br>
<br>
<br>
/// Encoded the `Data` as a Base64-encoded string. This is the default strategy.<br>
<br>
<br>
case<br>
base64<br>
<br>
<br>
/// Encode the `Data` as a custom value encoded by the given closure.<br>
<br>
<br>
///<br>
<br>
<br>
/// If the closure fails to encode a value into the given encoder, the encoder will encode an empty `.default` container in its place.<br>
<br>
<br>
case custom((_ value: Data, _ encoder: Encoder) throws -> Void)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use for non-JSON-conforming floating-point values (IEEE 754 infinity and NaN).<br>
<br>
<br>
public enum NonConformingFloatEncodingStrategy {<br>
<br>
<br>
/// Throw upon encountering non-conforming values. This is the default strategy.<br>
<br>
<br>
case `throw<br>
`<br>
<br>
<br>
/// Encode the values using the given representation strings.<br>
<br>
<br>
case convertToString(positiveInfinity: String, negativeInfinity: String, nan: String)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The output format to produce. Defaults to `.compact`.<br>
<br>
open<br>
var outputFormatting: OutputFormatting<br>
<br>
<br>
<br>
/// The strategy to use in encoding dates. Defaults to `.deferredToDate`.<br>
<br>
open<br>
var dateEncodingStrategy: DateEncodingStrategy<br>
<br>
<br>
<br>
/// The strategy to use in encoding binary data. Defaults to `.base64`.<br>
<br>
open<br>
var dataEncodingStrategy: DataEncodingStrategy<br>
<br>
<br>
<br>
/// The strategy to use in encoding non-conforming numbers. Defaults to `.throw`.<br>
<br>
open<br>
var nonConformingFloatEncodingStrategy: NonConformingFloatEncodingStrategy<br>
}<br>
<br>
<br>
open<br>
class JSONDecoder {<br>
<br>
<br>
// MARK: Top-Level Decoding<br>
<br>
<br>
<br>
/// Decodes a top-level value of the given type from the given JSON representation.<br>
<br>
<br>
///<br>
<br>
<br>
/// - parameter type: The type of the value to decode.<br>
<br>
<br>
/// - parameter data: The data to decode from.<br>
<br>
<br>
/// - returns: A value of the requested type.<br>
<br>
<br>
/// - throws: `CocoaError.coderReadCorrupt` if values requested from the payload are corrupted, or if the given data is not valid JSON.<br>
<br>
<br>
/// - throws: An error if any value throws an error during decoding.<br>
<br>
open<br>
func decode<Value : Codable>(_ type: Value.Type, from data: Data) throws -> Value<br>
<br>
<br>
<br>
// MARK: Customization<br>
<br>
<br>
<br>
/// The strategy to use for decoding `Date` values.<br>
<br>
<br>
public enum DateDecodingStrategy {<br>
<br>
<br>
/// Defer to `Date` for decoding. This is the default strategy.<br>
<br>
<br>
case<br>
deferredToDate<br>
<br>
<br>
/// Decode the `Date` as a UNIX timestamp from a JSON number.<br>
<br>
<br>
case<br>
secondsSince1970<br>
<br>
<br>
/// Decode the `Date` as UNIX millisecond timestamp from a JSON number.<br>
<br>
<br>
case<br>
millisecondsSince1970<br>
<br>
<br>
/// Decode the `Date` as an ISO-8601-formatted string (in RFC 3339 format).<br>
<br>
@<br>
available(OSX 10.12, iOS 10.0, watchOS 3.0, tvOS 10.0, *)<br>
<br>
<br>
case<br>
iso8601<br>
<br>
<br>
/// Decode the `Date` as a string parsed by the given formatter.<br>
<br>
<br>
case formatted(DateFormatter)<br>
<br>
<br>
<br>
/// Decode the `Date` as a custom value decoded by the given closure.<br>
<br>
<br>
case custom((_ decoder: Decoder) throws -> Date)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use for decoding `Data` values.<br>
<br>
<br>
public enum DataDecodingStrategy {<br>
<br>
<br>
/// Decode the `Data` from a Base64-encoded string. This is the default strategy.<br>
<br>
<br>
case<br>
base64<br>
<br>
<br>
/// Decode the `Data` as a custom value decoded by the given closure.<br>
<br>
<br>
case custom((_ decoder: Decoder) throws -> Data)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use for non-JSON-conforming floating-point values (IEEE 754 infinity and NaN).<br>
<br>
<br>
public enum NonConformingFloatDecodingStrategy {<br>
<br>
<br>
/// Throw upon encountering non-conforming values. This is the default strategy.<br>
<br>
<br>
case `throw<br>
`<br>
<br>
<br>
/// Decode the values from the given representation strings.<br>
<br>
<br>
case convertFromString(positiveInfinity: String, negativeInfinity: String, nan: String)<br>
<br>
<br>
}<br>
<br>
<br>
<br>
/// The strategy to use in decoding dates. Defaults to `.deferredToDate`.<br>
<br>
open<br>
var dateDecodingStrategy: DateDecodingStrategy<br>
<br>
<br>
<br>
/// The strategy to use in decoding binary data. Defaults to `.base64`.<br>
<br>
open<br>
var dataDecodingStrategy: DataDecodingStrategy<br>
<br>
<br>
<br>
/// The strategy to use in decoding non-conforming numbers. Defaults to `.throw`.<br>
<br>
open<br>
var nonConformingFloatDecodingStrategy: NonConformingFloatDecodingStrategy<br>
}<br>
Usage:<br>
<br>
var encoder = JSONEncoder()<br>
<br>
encoder<br>
.dateEncodingStrategy = .<br>
iso8601<br>
encoder<br>
.dataEncodingStrategy = .custom(myBase85Encoder)<br>
<br>
<br>
<br>
// Since JSON does not natively allow for infinite or NaN values, we can customize strategies for encoding these non-conforming values.<br>
<br>
encoder<br>
.nonConformingFloatEncodingStrategy = .convertToString(positiveInfinity: "INF", negativeInfinity: "-INF", nan: "NaN")<br>
<br>
<br>
<br>
// MyValue conforms to Codable<br>
let topLevel = MyValue(...)<br>
<br>
<br>
<br>
let payload: Data<br>
do {<br>
<br>
payload<br>
= try encoder.encode(topLevel)<br>
} catch {<br>
<br>
<br>
// Some value threw while encoding.<br>
}<br>
<br>
<br>
<br>
// ...<br>
<br>
<br>
<br>
var decoder = JSONDecoder()<br>
<br>
decoder<br>
.dateDecodingStrategy = .<br>
iso8601<br>
decoder<br>
.dataDecodingStrategy = .custom(myBase85Decoder)<br>
<br>
<br>
<br>
// Look for and match these values when decoding `Double`s or `Float`s.<br>
<br>
decoder<br>
.nonConformingFloatDecodingStrategy = .convertFromString(positiveInfinity: "INF", negativeInfinity: "-INF", nan: "NaN")<br>
<br>
<br>
<br>
let topLevel: MyValue<br>
do {<br>
<br>
topLevel<br>
= try decoder.decode(MyValue.self, from: payload)<br>
} catch {<br>
<br>
<br>
// Data was corrupted, or some value threw while decoding.<br>
}<br>
It should be noted here that JSONEncoder and JSONDecoder do not themselves conform to Encoder and Decoder; instead, they contain private nested types which do conform to Encoder and Decoder, which are passed to values' encode(to:)and init(from:). This is because JSONEncoder and JSONDecoder must present a different top-level API than they would at intermediate levels.<br>
<br>
Property List<br>
<br>
We also intend to support the property list format, with PropertyListEncoder and PropertyListDecoder:<br>
<br>
open class PropertyListEncoder {<br>
<br>
<br>
// MARK: Top-Level Encoding<br>
<br>
<br>
<br>
/// Encodes the given top-level value and returns its property list representation.<br>
<br>
<br>
///<br>
<br>
<br>
/// - parameter value: The value to encode.<br>
<br>
<br>
/// - returns: A new `Data` value containing the encoded property list data.<br>
<br>
<br>
/// - throws: An error if any value throws an error during encoding.<br>
<br>
open<br>
func encode<Value : Codable>(_ value: Value) throws -> Data<br>
<br>
<br>
<br>
// MARK: Customization<br>
<br>
<br>
<br>
/// The output format to write the property list data in. Defaults to `.binary`.<br>
<br>
open<br>
var outputFormat: PropertyListSerialization.PropertyListFormat<br>
}<br>
<br>
<br>
open<br>
class PropertyListDecoder {<br>
<br>
<br>
// MARK: Top-Level Decoding<br>
<br>
<br>
<br>
/// Decodes a top-level value of the given type from the given property list representation.<br>
<br>
<br>
///<br>
<br>
<br>
/// - parameter type: The type of the value to decode.<br>
<br>
<br>
/// - parameter data: The data to decode from.<br>
<br>
<br>
/// - returns: A value of the requested type.<br>
<br>
<br>
/// - throws: `CocoaError.coderReadCorrupt` if values requested from the payload are corrupted, or if the given data is not a valid property list.<br>
<br>
<br>
/// - throws: An error if any value throws an error during decoding.<br>
<br>
open<br>
func decode<Value : Codable>(_ type: Value.Type, from data: Data) throws -> Value<br>
<br>
<br>
<br>
/// Decodes a top-level value of the given type from the given property list representation.<br>
<br>
<br>
///<br>
<br>
<br>
/// - parameter type: The type of the value to decode.<br>
<br>
<br>
/// - parameter data: The data to decode from.<br>
<br>
<br>
/// - parameter format: The parsed property list format.<br>
<br>
<br>
/// - returns: A value of the requested type along with the detected format of the property list.<br>
<br>
<br>
/// - throws: `CocoaError.coderReadCorrupt` if values requested from the payload are corrupted, or if the given data is not a valid property list.<br>
<br>
<br>
/// - throws: An error if any value throws an error during decoding.<br>
<br>
open<br>
func decode<Value : Codable>(_ type: Value.Type, from data: Data, format: inout PropertyListSerialization.PropertyListFormat) throws -> Value<br>
}<br>
Usage:<br>
<br>
let encoder = PropertyListEncoder()<br>
let topLevel = MyValue(...)<br>
let payload: Data<br>
do {<br>
<br>
payload<br>
= try encoder.encode(topLevel)<br>
} catch {<br>
<br>
<br>
// Some value threw while encoding.<br>
}<br>
<br>
<br>
<br>
// ...<br>
<br>
<br>
<br>
let decoder = PropertyListDecoder()<br>
let topLevel: MyValue<br>
do {<br>
<br>
topLevel<br>
= try decoder.decode(MyValue.self, from: payload)<br>
} catch {<br>
<br>
<br>
// Data was corrupted, or some value threw while decoding.<br>
}<br>
Like with JSON, PropertyListEncoder and PropertyListDecoder also provide private nested types which conform to Encoder and Decoder for performing the archival.<br>
<br>
Foundation-Provided Errors<br>
<br>
Along with providing the above encoders and decoders, we would like to promote the use of a common set of error codes and messages across all new encoders and decoders. A common vocabulary of expected errors allows end-users to write code agnostic about the specific encoder/decoder implementation they are working with, whether first-party or third-party:<br>
<br>
extension CocoaError.Code {<br>
<br>
<br>
/// Thrown when a value incompatible with the output format is encoded.<br>
<br>
<br>
public static var coderInvalidValue: CocoaError.Code<br>
<br>
<br>
<br>
/// Thrown when a value of a given type is requested but the encountered value is of an incompatible type.<br>
<br>
<br>
public static var coderTypeMismatch: CocoaError.Code<br>
<br>
<br>
<br>
/// Thrown when read data is corrupted or otherwise invalid for the format. This value already exists today.<br>
<br>
<br>
public static var coderReadCorrupt: CocoaError.Code<br>
<br>
<br>
<br>
/// Thrown when a requested key or value is unexpectedly null or missing. This value already exists today.<br>
<br>
<br>
public static var coderValueNotFound: CocoaError.Code<br>
}<br>
<br>
<br>
<br>
// These reexpose the values above.<br>
extension CocoaError {<br>
<br>
<br>
public static var coderInvalidValue: CocoaError.Code<br>
<br>
<br>
<br>
public static var coderTypeMismatch: CocoaError.Code<br>
}<br>
The localized description strings associated with the two new error codes are:<br>
<br>
• .coderInvalidValue: "The data is not valid for encoding in this format."<br>
• .coderTypeMismatch: "The data couldn't be read because it isn't in the correct format." (Precedent from NSCoderReadCorruptError.)<br>
All of these errors will include the coding key path that led to the failure in the error's userInfo dictionary under NSCodingKeyContextErrorKey, along with a non-localized, developer-facing failure reason under NSDebugDescriptionErrorKey.<br>
<br>
NSKeyedArchiver & NSKeyedUnarchiver Changes<br>
<br>
Although our primary objectives for this new API revolve around Swift, we would like to make it easy for current consumers to make the transition to Codable where appropriate. As part of this, we would like to bridge compatibility between new Codabletypes (or newly-Codable-adopting types) and existing NSCoding types.<br>
<br>
To do this, we want to introduce changes to NSKeyedArchiver and NSKeyedUnarchiver in Swift that allow archival of Codable types intermixed with NSCoding types:<br>
<br>
// These are provided in the Swift overlay, and included in swift-corelibs-foundation.<br>
extension NSKeyedArchiver {<br>
<br>
<br>
public func encodeCodable(_ codable: Codable?, forKey key: String) { ... }<br>
}<br>
<br>
<br>
<br>
extension NSKeyedUnarchiver {<br>
<br>
<br>
public func decodeCodable<T : Codable>(_ type: T.Type, forKey key: String) -> T? { ... }<br>
}<br>
NOTE: Since these changes are being made in extensions in the Swift overlay, it is not yet possible for these methods to be overridden. These can therefore not be added to NSCoder, since NSKeyedArchiver and NSKeyedUnarchiver would not be able to provide concrete implementations. In order to call these methods, it is necessary to downcast from an NSCoder to NSKeyedArchiver/NSKeyedUnarchiver directly. Since subclasses of NSKeyedArchiver and NSKeyedUnarchiver in Swift will inherit these implementations without being able to override them (which is wrong), we will NSRequiresConcreteImplementation() dynamically in subclasses.<br>
The addition of these methods allows the introduction of Codable types into existing NSCoding structures, allowing for a transition to Codable types where appropriate.<br>
<br>
Refining encode(_:forKey:)<br>
<br>
Along with these extensions, we would like to refine the import of -[NSCoder encodeObject:forKey:], which is currently imported into Swift as encode(_: Any?, forKey: String). This method currently accepts Objective-C and Swift objects conforming to NSCoding (non-conforming objects produce a runtime error), as well as bridgeable Swift types (Data, String, Array, etc.); we would like to extend it to support new Swift Codable types, which would otherwise produce a runtime error upon call.<br>
<br>
-[NSCoder encodeObject:forKey:] will be given a new Swift name of encodeObject(_:forKey:), and we will provide a replacement encode(_: Any?, forKey: String) in the overlay which will funnel out to either encodeCodable(_:forKey:) or encodeObject(_:forKey:) as appropriate. This should maintain source compatibility for end users already calling encode(_:forKey:), as well as behavior compatibility for subclassers of NSCoderand NSKeyedArchiver who may be providing their own encode(_:forKey:).<br>
<br>
Semantics of Codable Types in Archives<br>
<br>
There are a few things to note about including Codable values in NSKeyedArchiverarchives:<br>
<br>
• Bridgeable Foundation types will always bridge before encoding. This is to facilitate writing Foundation types in a compatible format from both Objective-C and Swift<br>
• On decode, these types will decode either as their Objective-C or Swift version, depending on user need (decodeObject(forKey:) will decode as an Objective-C object; decodeCodable(_:forKey:) as a Swift value)<br>
• User types, which are not bridgeable, do not write out a $class and can only be decoded in Swift. In the future, we may add API to allow Swift types to provide an Objective-C class to decode as, effectively allowing for user bridging across archival<br>
Foundation Types Adopting Codable<br>
<br>
The following Foundation Swift types will be adopting Codable, and will encode as their bridged types when encoded through NSKeyedArchiver, as mentioned above:<br>
<br>
• AffineTransform<br>
• Calendar<br>
• CharacterSet<br>
• Date<br>
• DateComponents<br>
• DateInterval<br>
• Decimal<br>
• IndexPath<br>
• IndexSet<br>
• Locale<br>
• Measurement<br>
• Notification<br>
• PersonNameComponents<br>
• TimeZone<br>
• URL<br>
• URLComponents<br>
• URLRequest<br>
• UUID<br>
Along with these, the Array, Dictionary, and Set types will gain Codableconformance (as part of the Conditional Conformance feature), and encode through NSKeyedArchiver as NSArray, NSDictionary, and NSSet respectively.<br>
<br>
Source compatibility<br>
The majority of this proposal is additive. The changes to NSKeyedArchiver are intended to be non-source-breaking changes, and non-behavior-breaking changes for subclasses in Objective-C and Swift.<br>
<br>
Effect on ABI stability<br>
The addition of this API will not be an ABI-breaking change. However, this will add limitations for changes in future versions of Swift, as parts of the API will have to remain unchanged between versions of Swift (barring some additions, discussed below).<br>
<br>
Effect on API resilience<br>
Much like new API added to the standard library, once added, some changes to this API will be ABI- and source-breaking changes. Changes to the new encoder and decoder classes provided above will be restricted as described in the library evolution document in the Swift repository; in particular, the removal of methods or nested types or changes to argument types will break client behavior. Additionally, additions to provided options enums will be a source-breaking change for users performing an exhaustive switch over their cases; removal of cases will be ABI-breaking.<br>
<br>
Alternatives considered<br>
None. This is a companion to the Swift Archival and Serialization API.<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
swift-evolution@swift.org<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="color:#999">https://lists.swift.org/mailman/listinfo/swift-evolution</a></p>
</blockquote></blockquote></div>
<div style="white-space:normal">
</div>
</div>
</body>
</html>