[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