For the benefit of unkeyed containers, coding paths currently contain optional `CodingKey`s — unkeyed containers are allowed to report a `nil` key in a path. However, this is unhelpful for debugging purposes, or inspecting the coding path for context, since any unkeyed container simply reports `nil`, whether it’s at index 1 or 1000.
Now all containers are required to report a non-optional CodingKey for their segment of the coding path, and coding paths are now exposed as `[CodingKey]`.
If JSONSerialization or PropertyListSerialization throw errors during encoding or decoding, the error should be exposed as an EncodingError or DecodingError
CustomNSError briding only works when the CustomNSError conformance is in the same module as the original error declaration. We need to sink these down into the standard library.
* Add deferredToData strategy on encode and decode
* Rename base64{Encode,Decode} to base64 (missed this in previous fixes)
* Add unit test to confirm behavior
* Update {JSON,PropertyList}Decoder to allow superDecoder()s to wrap
null value so current implementations of collections can decode
contained objects from nil
To make it slightly easier to tell at a glance if a method is
implemented as part of API (public/open), shared implementation detail
(fileprivate), or implementation detail meaningful only to a given type
(private).
Allow JSONEncoder/JSONDecoder to intercept Decimal values so they get
a numeric representation in JSON (instead of their default keyed
implementation).
On encode, we previously treated every container request as a push;
instead, we should allow the same container type to be requested
multiple times so a class can pass its Encoder directly to its
superclass if it needs to.
The unarchiveTopLevelObjectWithData which returns Any? (instead of
AnyObject?) was added in Swift 4 and has only shipped in the betas so
far. Instead of adding new overloads which take different types, we
should just fix this one and call it a day.
We missed a few NSKeyedUnarchiver methods during our original renaming
for Swift — some of these methods still take NSData when they can take
Data. We can add Data variants which bridge to NSData to fix this in a
backwards-compatible way.
This is consistent with imported error codes, which are always
Hashable. URLError.Code was also Hashable in Swift 3.1 by virtue of
being defined as an enum; the change to a struct broke that.
rdar://problem/32066434
Logs a warning the first time a problematic class is archived or
unarchived. We expect people to actually fix these issues, so the
performance of the warning isn't too important.
Sample output:
[timestamp] Attempting to archive Swift class '_Test.Outer.ArchivedThenUnarchived', which does not have a stable runtime name.
[timestamp] Use the 'objc' attribute to ensure that the runtime name will not change: "@objc(_TtCC5_Test5Outer22ArchivedThenUnarchived)"
[timestamp] If there are no existing archives containing this class, you can choose a unique, prefixed name instead: "@objc(ABCArchivedThenUnarchived)"
Finishes rdar://problem/32414508
