Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 8:55 PM, Charles Srstka via swift-evolution > wrote: > >> On Jan 5, 2016, at 8:29 PM, Greg Parker > > wrote: >> >>> >>> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jan

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

On Jan 5, 2016, at 4:09 PM, Jordan Rose via swift-evolution wrote: >> We have some declaration modifiers (e.g., access-control modifiers) and >> attributes (e.g., availability) that distribute in this manner from the >> extension to its members. My only hesitation here is that @objc itself >>

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I stand corrected. Félix > Le 5 janv. 2016 à 22:19:28, Charles Srstka a écrit > : > >> On Jan 5, 2016, at 9:06 PM, Félix Cloutier > > wrote: >> >> The linker is smart enough to get rid of frameworks that you don't actually >> use. >> >> Félix > > > objc_copyClass

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 9:06 PM, Félix Cloutier wrote: > > The linker is smart enough to get rid of frameworks that you don't actually > use. > > Félix objc_copyClassList leaves a value of 14694 in classCount. When I just link against Foundation it only gives 1581. otool says: $ otool -L test

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

The linker is smart enough to get rid of frameworks that you don't actually use. Félix > Le 5 janv. 2016 à 21:55:17, Charles Srstka via swift-evolution > a écrit : > >> On Jan 5, 2016, at 8:29 PM, Greg Parker > > wrote: >> >>> >>> On Jan 5, 2016, at 3:37 PM, Charles

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 8:29 PM, Greg Parker wrote: > >> >> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor >> > wrote: >>> >>> There are better mechanisms for

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution > wrote: > >> On Jan 5, 2016, at 11:52 AM, Douglas Gregor > > wrote: >> >> There are better mechanisms for this than +load. But one would have to deal >> with the dylib loading issue and the need to enu

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 20:59, Douglas Gregor via swift-evolution > wrote: > >> >> On Jan 4, 2016, at 8:54 PM, Kevin Lundberg > > wrote: >> >> I like this idea, but I would imagine that for an extension with many >> functions in it, requiring @nonobjc on each one wou

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 11:52 AM, Douglas Gregor wrote: > > There are better mechanisms for this than +load. But one would have to deal > with the dylib loading issue and the need to enumerate root classes to get to > a complete implementation. Frankly, I don’t think this level of Objective-C > r

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 3:40 AM, Andrew Bennett wrote: > > I'm on the fence here, I think it's a good solution if a project has ongoing > objc dependencies. If the Objective-C runtime is there, you have ongoing Objective-C dependencies: we call them Cocoa and Cocoa Touch ;) > > However I have

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 5:41 AM, Charles Srstka wrote: > >> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> There is no direct way to implement Objective-C entry points for protocol >> extensions. One would effectively have to in

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 3:51 AM, Andrey Tarantsov wrote: > > I'm against this, because I often write extensions on Apple classes (like, > say, UIColor) that are only intended to be used from Swift, in a pure-Swift > project, and I need no stinking' @nonobjc in there. You are misreading my propos

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Extensions on classes already work and I can't see them requiring @objc or @nonobjc. It's extensions on protocols that don't work from Objective-C. The way I understand it, Doug suggests a warning/error for extensions on @objc protocols, and a @nonobjc attribute to shut it up. Your point may st

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution > wrote: > > 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 someh

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm against this, because I often write extensions on Apple classes (like, say, UIColor) that are only intended to be used from Swift, in a pure-Swift project, and I need no stinking' @nonobjc in there. How much of a problem can this surprise be? You call a method, the compiler tells you it's n

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

I'm on the fence here, I think it's a good solution if a project has ongoing objc dependencies. However I have a few issues/suggestions: 1) If a project is iteratively migrating from objc to swift, as I'm sure many are (a large project I'm working on included), then it would make that job much mo

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 8:58 PM, John Joyce 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_as

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 8:54 PM, Kevin Lundberg 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

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

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 > On Jan 5, 20

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 4, 2016, at 8:49 PM, Félix Cloutier wrote: > > For the folks who don't mix Swift and Objective-C that much, extensions on > @objc classes are exposed to the Objective-C runtime, so there is a > discrepancy here. I'm not passionate about the outcome, just dropping the > info. Right.

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

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 {}

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

For the folks who don't mix Swift and Objective-C that much, extensions on @objc classes are exposed to the Objective-C runtime, so there is a discrepancy here. I'm not passionate about the outcome, just dropping the info. Félix > Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution

[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

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