<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 26, 2017, at 8:23 PM, Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline">On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""><blockquote type="cite" class="">On Mar 24, 2017, at 10:09 AM, Douglas Gregor &lt;<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>&gt; wrote:</blockquote><blockquote type="cite" class="">Plus, inheritance from an Objective-C class is often incidental: you do it because you need an NSObjectProtocol conformance, or something else expects NSObject. I haven’t heard of developers inheriting from NSObject solely to get @objc inference for their members.<br class=""></blockquote><br class="">You do it because you need a particular object to interact with Objective-C. In that circumstance, I don't think the compiler is wrong to assume that you want to expose as many members as possible to Objective-C.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">In my experience, there are two types of projects nowadays (in regards to Swift-ObjC interop):</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">1) New projects that are generally pure Swift or include some ObjC files as a bridge for interaction with C++ or some other stuff Swift can't currently do. In such case, the NSObject inheritence is usually due to the NSObjectProtocol requirement defined by most delegates in Cocoa (Touch). In such cases, you're usually expecting just the delegate methods to be exposed to the ObjC runtime.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div>The NSObjectProtocol requirement is something that isn’t technically even necessary in Swift. Every Swift class already defines implementations for anything in NSObjectProtocol; we could, in fact, completely erase NSObjectProtocol (or just call it AnyObject) and it would reduce the reliance of Swift programs on NSObject.</div><div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">2) Projects with mixed Swift/ObjC code, where you usually really need to expose as many members to ObjC as possible. As you need to communicate with your objects from ObjC, you need to indeed have most declaractions as @objc.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I do wonder about the “most” here; it implies that “most” non-private APIs that aren’t overrides and aren’t satisfying @objc protocol requirements are used from Objective-C.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">As it is, however, just the public API and it's usually just a temporary fix, I'm personally fine with marking them as @objc. By "temporary fix" I mean that with the future ahead, the ObjC code will eventually get rewritten to Swift, so it's a fix as long as you need to expose the API to ObjC.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>Even if that isn’t the future for that codebase, @objc documents the use of an API across languages.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">All things considered, I do agree that it's a huge change that would come too quickly and would agree on deprecating this in Swift 4 and removing in Swift 5.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Please keep in mind that for a one-person team such as myself, testing of e.g. 5 apps thoroughly simply takes a lot of time and as the releases of Swift are usually (or have been historically) in line with releases of new OS versions, there's a lot of pressure during those months leading to these releases on developers and postponing this change while giving them the tools (deprecation messages, breakpoint symbols) would IMHO help a lot.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>Brent mentioned this desire for a longer deprecation cycle; I’ll reply to his message on the topic.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div><div><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">you already have to specify `dynamic` to avoid optimizations;<br class=""></blockquote><br class="">Conceptually, ‘dynamic’ is orthogonal to ‘@objc’. In today’s implementation, we can only implement ‘dynamic’ via the Objective-C runtime, hence this proposal’s requirement to write both.<br class=""></blockquote><br class="">I understand that, but again, I think it's defensible for the compiler to assume that, if you want dynamic behavior in a class where you've already enabled Objective-C interop, you probably want that dynamic behavior to be compatible with Objective-C.<br class=""><br class="">I guess we just take different standpoints on Objective-C interop. My belief is that, if you state an intention to have a type interoperate with Objective-C, Swift should try to expose as many of its members to Objective-C as possible. I think you believe that Swift should expose as *little* as possible to Objective-C.<br class=""><br class="">Because of that difference, I actually think I'd be *more* likely to support removing inference by requiring an explicit `@nonobjc` on members of Objective-C-compatible classes which aren't compatible with Objective-C. That is, writing:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>class Foo: NSObject {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>var bar: Int?<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}<br class=""><br class="">Is an error; you have to write:<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>class Foo: NSObject {<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span><span class="Apple-tab-span" style="white-space: pre;">        </span>@nonobjc var bar: Int?<br class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>}<br class=""><br class="">I don't really like that answer very much, but I like it more than I would like requiring `@objc` if `bar` were a plain `Int`.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Would you like the request for bridging notarized and filed in triplicate?<br class=""></blockquote></blockquote><br class="">(By the way, in reading this later, I realized this part might have sounded a little too angry. I was trying to be funny. Nobody complained, but I'm sorry if I missed the mark here.)<br class=""><br class="">--<span class="Apple-converted-space">&nbsp;</span><br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></div></blockquote></div><br class=""></body></html>