> On Mar 15, 2017, at 9:19 PM, Brent Royal-Gordon <[email protected]> > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
