[swift-evolution] Notification.Name

Ben Rimmington me at benrimmington.com
Thu Jun 30 11:10:16 CDT 2016

[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?

For example, in <Foundation/NSTimeZone.h> by adding the `swift_name` attribute:

	FOUNDATION_EXPORT NSNotificationName const NSSystemTimeZoneDidChangeNotification

The constant should hopefully be imported into Swift as:

	extension TimeZone {
	    public static let systemTimeZoneDidChange: NSNotification.Name

-- 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

More information about the swift-evolution mailing list