<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Brent,<div class=""><br class=""></div><div class="">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 <i class="">type</i> of it is of course Notification.Name.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">- Tony</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Not 100% sure this belongs here, but I'll bite.<br class=""><br class="">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:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Notification.Name.NSSystemTimeZoneDidChange<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Notification.Name.NSThreadWillExit<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Notification.Name.NSURLCredentialStorageChanged<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Notification.Name.NSUbiquityIdentityDidChange<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Notification.Name.NSUndoManagerCheckpoint<br class=""><br class="">I think these would be a lot better off as:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>TimeZone.systemTimeZoneDidChange<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Thread.willExit<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>URLCredentialStorage.changed<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>FileManager.ubiquityIdentityDidChange<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>UndoManager.checkpoint<br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">So, what's the best way to pursue fixing this issue?<br class=""><br class="">1. A new proposal, perhaps introducing `swift_wrapper(struct,prefix_matched)`?<br class=""><br class="">2. An amendment to SE-0033?<br class=""><br class="">3. A radar filed with the Foundation team?<br class=""><br class="">4. A blizzard of radars filed with *every* framework team?<br class=""><br class="">5. Deferral to post-Swift 3?<br class=""><br class=""><br class=""><br class="">[1] <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md</a><br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>