> On Mar 16, 2017, at 5:37 PM, Itai Ferber <[email protected]> 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? > 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. > 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
