[swift-evolution] [Proposal] Foundation Swift Archival & Serialization
brent at architechies.com
Thu Mar 16 01:41:35 CDT 2017
> On Mar 15, 2017, at 9:19 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> I think we'd be better off having `encode(_:forKey:)` not take an optional; instead, we should have `Optional` conform to `Codable` and behave in some appropriate way. Exactly how to implement it might be a little tricky because of nested optionals; I suppose a `none` would have to measure how many levels of optionality there are between it and a concrete value, and then encode that information into the data. I think our `NSNull` bridging is doing something broadly similar right now.
> I know that this is not the design you would use in Objective-C, but Swift uses `Optional` differently from how Objective-C uses `nil`. Swift APIs consider `nil` and absent to be different things; where they can both occur, good Swift APIs use doubled-up Optionals to be precise about the situation. I think the design needs to be a little different to accommodate that.
Re-reading this after sending it, I realized I should probably be a lot more concrete about what I envision here.
Basically, what I think is:
* There should be primitives for `encode(_ value: NSNull)` and `decode(_ type: NSNull.Type)`. Yes, even though it's a singleton. In JSON, this should emit/read a `null`; in plist format, I suppose it will simply have to interpret absence of the corresponding key as `null`, because there's nothing better we can do there.
* An `Optional.some(x)` should encode as an `x` would.
* An `Optional.none`, where `Wrapped` is not itself an `Optional`, should encode as an `NSNull`.
* An `Optional.none`, where `Wrapped` *is* itself an `Optional`, should encode as one of the Swift runtime's magic optional sentinel objects.
That will do the best job we can manage of correctly representing nested optionals.
More information about the swift-evolution