> On Mar 17, 2017, at 1:23 PM, Brent Royal-Gordon via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
