Re: Elementary NSUserDefaults Question
Re: Elementary NSUserDefaults Question
- Subject: Re: Elementary NSUserDefaults Question
- From: Quincey Morris <email@hidden>
- Date: Wed, 07 Dec 2016 17:36:11 -0800
- Feedback-id: 167118m:167118agrif8a:167118sR1CE9f7De:SMTPCORP
On Dec 7, 2016, at 16:39 , Charles Srstka <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden