[swift-evolution] Notification.Name

[Michael Ilseman]

> On Jun 30, 2016, at 9:10 AM, Ben Rimmington <me at benrimmington.com> wrote:
> 
> [Cc: Michael Ilseman]
> 
>> On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Not 100% sure this belongs here, but I'll bite.
>> 
>> The new `Notification.Name` type is a beautiful application of SE-0033 "Import Objective-C Constants as Swift Types"[1] which removes a lot of boilerplate. However,  I think it puts the resulting constants in the wrong place. They all get piled into `Notification.Name`, resulting in:
>> 
>> 	Notification.Name.NSSystemTimeZoneDidChange
>> 	Notification.Name.NSThreadWillExit
>> 	Notification.Name.NSURLCredentialStorageChanged
>> 	Notification.Name.NSUbiquityIdentityDidChange
>> 	Notification.Name.NSUndoManagerCheckpoint
>> 
>> I think these would be a lot better off as:
>> 
>> 	TimeZone.systemTimeZoneDidChange
>> 	Thread.willExit
>> 	URLCredentialStorage.changed
>> 	FileManager.ubiquityIdentityDidChange
>> 	UndoManager.checkpoint
>> 
>> Most of these could probably be inferred by prefix matching, but some, like `TimeZone.systemTimeZoneDidChange` and `FileManager.ubiquityIdentityDidChange`, would probably have to be done manually. There might even be a few which have no natural attachment point, though I can't think of any off the top of my head.
> 
> Is this another case where SE-0033 and SE-0044 can work together?
> <http://article.gmane.org/gmane.comp.lang.swift.evolution/19946 <http://article.gmane.org/gmane.comp.lang.swift.evolution/19946>>
> 
> For example, in <Foundation/NSTimeZone.h> by adding the `swift_name` attribute:
> 
> 	FOUNDATION_EXPORT NSNotificationName const NSSystemTimeZoneDidChangeNotification
> 	NS_SWIFT_NAME(TimeZone.systemTimeZoneDidChange);
> 
> The constant should hopefully be imported into Swift as:
> 
> 	extension TimeZone {
> 	    public static let systemTimeZoneDidChange: NSNotification.Name
> 	}
> 

That is certainly in the spirit of SE-0044, and anything that is “typified” from SE-0033 is valid host for import-as-member. There are a few bugs in that interaction that I’m currently working out (e.g. with opaque pointers), but I think it’s reasonable to allow users of swift_name to choose a host that is different from NSNotification. If your example doesn’t work, please file a JIRA.

> -- Ben
> 
>> To be clear, I don't think we want this behavior on all `swift_wrapper` types. For instance, the specified behavior is probably appropriate for `HKQuantityTypeIdentifier` and `NSErrorDomain`, the primary examples in SE-0033. But `Notification.Name` is a slightly different use from what we imagined for this feature, and I think it needs a slightly different behavior.
>> 
>> So, what's the best way to pursue fixing this issue?
>> 
>> 1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?
>> 
>> 2. An amendment to SE-0033?
>> 
>> 3. A radar filed with the Foundation team?
>> 
>> 4. A blizzard of radars filed with *every* framework team?
>> 
>> 5. Deferral to post-Swift 3?
>> 
>> 
>> 
>> [1] https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/f3a21d03/attachment.html>