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
<[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
