[swift-evolution] [Proposal] Foundation Swift Encoders

[Matthew Johnson]

Sent from my iPad

> On Mar 16, 2017, at 5:59 PM, Itai Ferber <iferber at apple.com> wrote:
> 
> On 16 Mar 2017, at 15:45, Matthew Johnson wrote:
> 
> > On Mar 16, 2017, at 5:37 PM, Itai Ferber <iferber at apple.com> wrote:
> 
> On 16 Mar 2017, at 14:48, Matthew Johnson wrote:
> 
> Thank you again for bringing these great proposals forward!
> 
> Thanks for reviewing it, and for your comments!
> 
> I only have a couple of questions about this proposal.
> 
> I noticed that the types in this proposal don’t conform to Encoder and Decoder. Is the plan to have them to provide private conforming types to Codable types they are asked to encode or decode?
> 
> Yes. This is because the top-level interface for encoding and decoding in JSON and plist is different from the intermediate interface that Encoder and Decoder offer. As such, the top-level types don’t conform to Encoder and Decoder, but vend out internal types which do.
> This makes sense. I was initially concerned about the meaning of mutating these values during encoding or decoding but it looks like that isn’t possible without some really nefarious code that passes a reference to the top-level encoder / decoder to an object that is getting encoded / decoded. What will you do if somebody actually does this?
> 
> The options are copied immutably into the internal types and the originals are not consulted during the process of encoding or decoding — we want to prevent exactly this.
> FWIW, you can see the current implementation of this on the implementation PR.
> 
> Why are the strategy and format properties readwrite instead of configured at initialization time? Is the intent that the encoder / decoder can be re-used with a different configuration in a subsequent call to encode or decode?
> 
> Yes. It’s also a mouthful to have them all as params in the constructor, especially if we add more options in the future.
> Taking them in an initializer would not need to be wordy - they could all specify default arguments.
> 
> Sure, but if you want to specify a lot of them…
> But, this is more of a stylistic argument. Six of one, half-dozen of another. The more useful thing is supporting mutation after initialization, which is a reasonable thing to want to do.
> 
Fair enough.  This makes sense given the rest of the details.  I'm glad to hear you're copying them to the internal types when starting encoding / decoding!  :)
> Finally, I agree with Brent’s comments regarding errors. I would prefer to see Foundation move away from NSError in favor of domain-specific error types. That said, the comment that this is a broader discussion for Foundation and not something to change in this proposal is reasonable. I hope Foundation will consider changing this in the future.
> 
> Thanks for your understanding — we will keep these concerns in mind.
> 
> Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/f7f5d0a5/attachment.html>