[swift-evolution] [Proposal] Foundation Swift Archival & Serialization

[Brent Royal-Gordon]

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

-- 
Brent Royal-Gordon
Architechies