> On Jan 4, 2016, at 8:58 PM, John Joyce <[email protected]> wrote:
>
> Would it not be possible to do the relative analog of Objective-C nullability
> macro sandwiches in Swift?
> And then allowing exceptions within the file to be called out explicitly with
> @nonobjc or @objc ?
> @begin_assume_nonobjc
> @end_assume_nonobjc
> @begin_assume_objc
> @begin_assume_objc
Ick :)
If we need to annotate several things at once, doing it an extension
granularity is good enough, because there’s essentially no cost to merging or
breaking apart extensions as needed.
- Doug
>> On Jan 5, 2016, at 1:54 PM, Kevin Lundberg via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I like this idea, but I would imagine that for an extension with many
>> functions in it, requiring @nonobjc on each one would get tedious very fast.
>> Could it be required (or at least allowed in addition to per-method
>> annotations) at the extension level?:
>>
>> @objc protocol P {}
>>
>> @nonobjc extension P {
>> func foo() { }
>> func bar() { }
>> func baz() { }
>> func blah() { }
>> // etc...
>> }
>>
>> I don’t know if this would have specific implementation ramifications over
>> only doing this on each method, if extensions cannot already be modified
>> with attributes. I can’t think of a case where I’ve seen annotations added
>> to protocol extensions, or any other extensions for that matter.
>>
>>
>>> On Jan 4, 2016, at 11:32 PM, Douglas Gregor via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hi all,
>>>
>>> We currently have a bit of a surprise when one extends an @objc protocol:
>>>
>>> @objc protocol P { }
>>>
>>> extension P {
>>> func bar() { }
>>> }
>>>
>>> class C : NSObject { }
>>>
>>> let c = C()
>>> print(c.respondsToSelector("bar")) // prints "false"
>>>
>>> because the members of the extension are not exposed to the Objective-C
>>> runtime.
>>>
>>> There is no direct way to implement Objective-C entry points for protocol
>>> extensions. One would effectively have to install a category on every
>>> Objective-C root class [*] with the default implementation or somehow
>>> intercept all of the operations that might involve that selector.
>>>
>>> Alternately, and more simply, we could require @nonobjc on members of @objc
>>> protocol extensions, as an explicit indicator that the member is not
>>> exposed to Objective-C. It’ll eliminate surprise and, should we ever find
>>> both the mechanism and motivation to make default implementations of @objc
>>> protocol extension members work, we could easily remove the restriction at
>>> that time.
>>>
>>> - Doug
>>>
>>> [*] Assuming you can enumerate them, although NSObject and the hidden
>>> SwiftObject cover the 99%. Even so, that it’s correct either, because the
>>> root class itself might default such a method, and the category version
>>> would conflict with it, so...
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
