[swift-evolution] [Proposal] Foundation Swift Encoders
Itai Ferber
iferber at apple.com
Thu Mar 16 15:19:30 CDT 2017
We’ll keep this in mind. :)
On 15 Mar 2017, at 19:58, Will Stanton wrote:
> Hello Itai,
>
> Thanks for your response and its explanations!
>
> Agreed that comprehension of multiple formats is important since there
> are a couple common ways of encoding JSON dates!
>
> Still, ISO 8601 appears pretty often (though I don’t have data on
> that, Stack Overflow says RFC 7493 I-JSON prefers ISO 8601;
> https://tools.ietf.org/html/rfc7493#section-4.3), and as other servers
> might make/handle a lot of JSON produced to/from the API, I think it
> would be disadvantageous to default to `deferredToDate` (if
> `deferredToDate` doesn't use the ISO 8601 format).
>
> As you mention, writers/readers have to agree on their format - my 2¢
> is that ISO 8601 would be more common, and so a better default, than a
> Unix or reference date timestamp.
>
> Regards,
> Will Stanton
>
>
> -—Gracias for the prediction :-)
>
>
>
>> On Mar 15, 2017, at 9:53 PM, Itai Ferber <iferber at apple.com> wrote:
>>
>> Hi Will,
>>
>> Thanks for your comments!
>> deferredToDate simply uses the default implementation that Date
>> provides — since it is not a primitive type like Int or String and
>> conforms to Codable itself, it will have an implementation of
>> init(from:) and encode(to:). It will have an implementation that
>> makes sense for Date in general, but since a big use-case for JSON
>> lies in talking to external servers which you don't control, allowing
>> for custom date formatting is important.
>>
>> To that end, although ISO 8601 may make sense for some applications
>> as the default, it is less efficient to format, encode, decode, and
>> parse than, say, writing out a UNIX timestamp as a Double (or
>> similar). Thus, the default is to allow Date to pick a representation
>> that best suits itself, and if you need customization, you have the
>> option to use it.
>>
>> Since Date makes a concrete decision about how to encode, both sides
>> will need to use deferredToDate for compatibility, in the same way
>> that they would have to agree about ISO 8601, or any of the other
>> options.
>>
>> HTH!
>>
>> — Itai
>>
>> P.S. About Xcode autocompletion slowdown, I don't know to be honest,
>> but I can't imagine it would be significant. Only certain types have
>> enc... or dec... and even then, the list of methods isn't that long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/573bb723/attachment.html>
More information about the swift-evolution
mailing list