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