[Cc: Michael Ilseman] > On 30 Jun 2016, at 03:13, Brent Royal-Gordon via swift-evolution > <[email protected]> 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> 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 } -- 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
