[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
Jonathan Hull
jhull at gbis.com
Sun Mar 19 21:33:27 CDT 2017
> On Mar 17, 2017, at 1:23 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>
>> (Also, is there any sense in adding `Date` to this set, since it needs special treatment in many of our formats?)
>>
>> We’ve considered adding Date to this list. However, this means that any format that is a part of this system needs to be able to make a decision about how to format dates. Many binary formats have no native representations of dates, so this is not necessarily a guarantee that all formats can make.
>>
>> Looking for additional opinions on this one.
>>
> I think that, if you're taking the view that you want to provide a set of pre-specified primitive methods as a list of things you want encoders to make a policy decision about, Date is a good candidate. But as I said earlier, I'd prefer to radically reduce the set of primitives, not add to it.
>
> IIUC, two of your three proposed, Foundation-provided coders need to do something special with dates; perhaps one of the three needs to do something special with different integer sizes and types. Think of that as a message about your problem domain.
Have you considered having a very small set of true primitives, and a larger set of optional primitives. For the optional primitives, a default implementation would be provided that converts it to/from one of the true primitives (e.g. date <—> string), but it would still provide an override point for formats that want to support it more directly.
Thanks,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170319/7dce0a9a/attachment.html>
More information about the swift-evolution
mailing list