[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Itai Ferber]

Hi Slava,

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 
> somehow?
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 
> (https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md 
> <https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md>) 
> 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.

Specifically:

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.

>
> Slava


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/d502f35a/attachment.html>