Uncomment NSUserDefaults dictionaryRepresentation #1086
Conversation
|
@swift-ci please test |
| @@ -93,7 +93,7 @@ keysToFetch that are not present in the returned dictionary | |||
| are not present in the domain. If keysToFetch is NULL, all | |||
| keys are fetched. */ | |||
| CF_EXPORT | |||
| CFDictionaryRef CFPreferencesCopyMultiple(_Nullable CFArrayRef keysToFetch, CFStringRef applicationID, CFStringRef userName, CFStringRef hostName); | |||
| _Nullable CFDictionaryRef CFPreferencesCopyMultiple(_Nullable CFArrayRef keysToFetch, CFStringRef applicationID, CFStringRef userName, CFStringRef hostName); | |||
There was a problem hiding this comment.
I don't think we have any other nullable annotations in CF headers. Can we just treat this as an IUO in Swift instead?
There was a problem hiding this comment.
That function does return NULL though and that header file has other _Nullable annotations, with a default of CF_ASSUME_NONNULL_BEGIN. So I don't see a problem with this change and it does fix an annoying warning.
Is it not a good idea to annotate as many of the function prototypes as possible over time? Or is there some downside to it?
There was a problem hiding this comment.
Without this annotation, Swift will reject (aPref._swiftObject) as? [NSString: Any] because it doesn't think _swiftObject is optional.
I had my doubt then I found functions like CFPreferencesCopyApplicationList and CFPreferencesCopyKeyList below actually has _Nullable annotations.
There was a problem hiding this comment.
Besides, as @spevans pointed out, it does return NULL in some condition. And the changes seems to work fine on both Linux & macOS. The only concern I have is the possibility of conflict if there will be any merging between the CF we used here & the CF in macOS.
There was a problem hiding this comment.
Ok, I think we'll just have to figure out what to do with this when we merge with Darwin.
|
@swift-ci test and merge |
The compiler no longer crashes for this method. Tested on macOS & Ubuntu 16.04