[swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol

[Brent Royal-Gordon]

> On Jun 29, 2016, at 6:07 PM, Kenny Leung via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 1. I think following the pattern of ErrorProtocol would be better

I don't think so. ErrorProtocol bridging uses the `domain` to figure out which concrete ErrorProtocol type to use, but NSNotification names are just plain strings with no internal structure, so it wouldn't be possible to bridge them back in the same way. Nor do you typically receive a bunch of unrelated notifications in one place and then have to sort them out into broad buckets in the same way—usually NotificationCenter handles all the testing for you. The resemblance between error enums and notification name constants is superficial.

> 2. It doesn’t explain why I can use String in one instance and not the other when they are both typed the same:
> 
> // Can use String or Notification.Name
>    @nonobjc final public func addObserver(_ observer: AnyObject, selector aSelector: Selector, name aName: Name, object anObject: AnyObject?)
> // Can only use Notification.Name
>    public func post(name aName: NSNotification.Name, object anObject: AnyObject?)

The generated headers show two overloads:

    public func addObserver(_ observer: AnyObject, selector aSelector: Selector, name aName: String?, object anObject: AnyObject?)
    @nonobjc final 
    public func addObserver(_ observer: AnyObject, selector aSelector: Selector, name aName: Name, object anObject: AnyObject?)

This looks like a bug to me—there ought to be one method which takes an optional Name, with the String variant hidden using the NS_REFINED_FOR_SWIFT macro. I'd file a radar if I were you.

-- 
Brent Royal-Gordon
Architechies