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.
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.
Matthew
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
