> On Jun 30, 2016, at 9:10 AM, Ben Rimmington <[email protected]> wrote: > > [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 > <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
