[swift-evolution] [Proposal] Foundation Swift Encoders

[Itai Ferber]

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](https://github.com/apple/swift/pull/8124).

>> 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 
>> mind.
>>
>> Matthew
>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170316/0f9df7ea/attachment.html>