[swift-evolution] [Proposal] Foundation Swift Encoders
iferber at apple.com
Thu Mar 16 17:37:08 CDT 2017
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
> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution