> On Jan 4, 2016, at 20:59, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Jan 4, 2016, at 8:54 PM, Kevin Lundberg <ke...@klundberg.com >> <mailto:ke...@klundberg.com>> 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. > > 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 > doesn’t distribute in this way, and I’d rather they not be inconsistent.
I'd be much happier with this if we could do "@nonobjc extension", and I have no problems with "@objc extension" (even if it's rare). I suppose that would be a separate proposal. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
