Hi Brent, In general, I agree with your idea that the scope of the name of these things is with the type it’s used for. The type of it is of course Notification.Name.
One thing we did in the short term to make this feature even remotely possible was to add an importer rule: global const NSStrings that end in ‘Notification’ are imported as Notification.Name.something — otherwise everyone would have to either cast these, or we’d have to audit the whole SDK to add an attribute to each one. I think we can probably do a better job of putting these where they belong with a combination of setting the attribute and using either API notes or the NS_SWIFT_NAME macro to get them into the right scope. Probably the only real way to accomplish this is to file radars on each relevant framework (including Foundation itself). Thanks, - Tony > On Jun 29, 2016, at 7:13 PM, 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. > > 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
