On Dec 7, 2016, at 16:39 , Charles Srstka <cocoa...@charlessoft.com> wrote:
>
> when I pass nil to UserDefaults’ set(forKey:) method in Swift 3 […] it ends
> up writing an NSNull instead of deleting the key […], since the method on
> UserDefaults takes an Any?
That sounds right. The case where it gives an opaquely wrapped nil is (I think)
where the API is Any rather than Any?.
For the record, I realized I said this bit wrong:
>> If you have a dictionary whose values are optional strings (say, [String:
>> String?], to be concrete), and you look up a key that has a value, you get a
>> result of type String?, which may or may not be nil. If you look up a key
>> that has no value, you get a result of “nil as String??”, with two levels of
>> optionality.
In fact, you’d always get a result of compile-time type String?? from the
dictionary lookup, but the value will be one:
1. nil as String?? (“Optional<Optional<String>>.none”)
2. nil as String? (“Optional<Optional<String>>.some
(Optional<String>.none)”)
3. non-nil (“Optional<Optional<String>>.some (String)”)
It’s still about the same level of confusing, though. In this scenario, #1 is
the absence of a value, #2 is the presence of a nil, and #3 is the presence of
a non-nil. #2 is the semantically problematic one, because it’s essentially the
presence of an absence.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
