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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
