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

[Douglas Gregor]

Sent from my iPhone

On Jun 29, 2016, at 6:51 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:

>> 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.

Right. ErrorProtocol is deeply ties with the Swift error-handling model and its interoperability with Objective-C. 

> 
>> 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.

This was an artifact of of an elaborate Foundation/Swift dance that didn't reach its conclusion for the first preview. It'll be fixed (with the string version going away and the other's name becoming optional).

  - Doug


> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution