[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
iferber at apple.com
Thu Mar 16 16:04:37 CDT 2017
Thanks for your comments!
On 16 Mar 2017, at 13:50, Slava Pestov wrote:
> Hi Itai,
> I’m wondering what the motivation is for keeping this as part of
> Foundation and not the standard library. It seems like you’re
> landing an implementation of this in the Foundation overlay on master,
> and another copy of all the code will have to go into
> swift-corelibs-foundation. This seems suboptimal. Or are there future
> plans to unify the Foundation overlay with corelibs-foundation
This has to be part of Foundation because `Data`, a Foundation type, is
one of the primitive types of serialization. This will be doubly true if
we decide to add `Date` as another primitive type.
I agree that this is suboptimal at the moment, but we will work to find
a way to keep the work in sync in a reasonable manner.
> Also the implementation uses some Foundation-isms (NSMutableArray,
> NSNumber) and it would be nice to stick with idiomatic Swift as much
> as possible instead.
Using the Foundation framework is just as idiomatic in Swift… ;)
In this specific case, we need collections with reference semantics
(`NSMutableArray` and `NSMutableDictionary`) and a concrete type-erased
number box (`NSNumber`); theres’s no reason to reinvent the wheel if
we already have exactly the tools we need.
The reference implementation at the moment goes through
`JSONSerialization`, which affects the specifics of its implementation.
This may change in the future.
> Finally you should take a look at the integer protocol work
> to replace the repetitive code surrounding primitive types, however I
> don’t know if this has landed in master yet.
As mentioned in other emails, the list of primitive types was carefully
chosen because we need to have a concrete list of types which consumers
can rely on being supported, and that `Encoder`s and `Decoder`s know
they _must_ support.
1. For binary formats, the difference between an `Int16` and an `Int64`
is significant. The `Encoder` would need to know that it’s received
one type or another, not just a `FixedWidthInteger`; this would involve
a runtime check of the concrete type of the argument
2. Any type can conform to these protocols — nothing is preventing me
from writing an `Int37` type conforming to `FixedWidthInteger` and
passing it in. Most encoders would really not know what to do with this
type (especially ones with binary formats), but the failure would be a
runtime one instead of a static one
* A concrete example of this is the `FloatingPoint` protocol.
`Float80` conforms to the protocol, but no common binary format I’ve
seen supports 80-bit floating-point values. We’d prefer to prevent
that statically by accepting only `Float` and `Double`
3. Consumers of the API then have no guarantees that a specific
`Encoder` supports the type that they need. Did the encoder remember to
support `UInt64` values? Similarly, `Encoder`s and `Decoder`s don’t
know what types they need to be considering. Am I supposed to handle
`UInt8` differently from `Int16`? With a list of concrete types, this
becomes immediately clear — both consumers and writers of `Encoder`s
have a clear contract.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution