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

[Itai Ferber]

I don’t think there’s much of a difference between adding an 
"optional" primitive (which has a default implementation in terms of a 
different primitive) and simply having that type adopt `Codable` itself 
and not be a primitive. You can still switch on the type dynamically 
(and we do), but you don’t need the optional overload for it.

On 19 Mar 2017, at 19:33, Jonathan Hull wrote:

> > 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/20170320/2b130958/attachment.html>