<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=""><div class="">Happy New Year!</div><div class=""><br class=""></div>To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the discussion this week.<br class=""><br class="">These are informal comments, intended to guide the proposals in directions that draw constructive feedback. You are welcome to ignore the feedback, agree with it, or disagree with it. As always, the formal decision doesn't happen until after the review period ends.<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="section" id="limiting-objc-inference" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14.399999618530273px;"><h3 class="" style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;">Limiting <code class="literal docutils" style="font-size: 1em;">@objc</code> inference<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2017-01-04.html#limiting-objc-inference" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p class="" style="text-align: justify;"><a class="external reference" href="https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/NNNN-objc-inference.md" style="font-weight: bold; text-decoration: none; color: rgb(137, 38, 1);">https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/NNNN-objc-inference.md</a></p><p class="" style="text-align: justify;">As discussed before the break, this pares back the inference of <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code>. Keep doing it for <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">NSManaged</span></code> and <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">IBOutlet</span></code> because those things are tightly tied to the Obj-C runtime.</p><p class="" style="text-align: justify;">Stop inferring it for <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamic</span></code> which lets us, in the future, do dynamic properly in a pure-Swift world. Also stop inferring <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> on subclasses of <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">NSObject</span></code>. The rules for when it’s inferred are too complex; there are a lot of selector collisions and the default selectors are usually poor because of the differences between Swift and Obj-C naming conventions; and it causes code bloat. All of these issues would go away.</p><p class="" style="text-align: justify;">We know that 6-8% of the binary size are thunks, but we don’t know how many of them are used, so we can’t assume that this change will cause 6-8% of the binary size to go away.</p><p class="" style="text-align: justify;">People use <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamic</span></code> for Core Data and KVO and providing your own property implementation. We can grep for <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamic</span></code> to see how much it’s used quantitatively. You can write <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span> <span class="pre">dynamic</span></code> in Swift 3, it’s allowed — in Swift 4 it will be required. We can add a fix-it or warning to add the expanded version; the user impact is pretty small.</p><p class="" style="text-align: justify;">The source compatibility story for <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">NSObject</span></code> subclasses is complicated. Recompiling Swift 3 code under Swift 4 causes a bunch of selectors to go away. If you’re lucky, you’re using them from Obj-C code in your project and get compile-time errors. If you’re unlucky, you’re doing something dynamic, and you’ll get runtime errors.</p><p class="" style="text-align: justify;">One recommended approach is, in Swift 3 mode, to put deprecation notes on the Obj-C headers where <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> is being inferred. We could have Swift 4 keep generating these declarations with an “unavailable” message, but even if you do that you still get unrecognized selector errors. On the other hand, marking them unavailable would give you a compile error instead of a compile warning.</p><p class="" style="text-align: justify;">This seems like a form of refactoring. The indexer knows what symbols are being used. Could we use that as part of the migrator?</p><p class="" style="text-align: justify;">An alternative approach is to make the migrator add <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> everywhere. In many places, the <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> is junk code that you don’t need, but the migrator doesn’t know which you need — adding it everywhere means we can be sure that your code is correct. There is some concern about people cargo-culting the correction.</p><p class="" style="text-align: justify;">You can’t have two declarations in Obj-C for the same selector, even if they’re both unavailable. So it becomes really hard to generate these from code after it has been migrated to Swift 4 — only the generated header printer is keeping track of what is a duplicate.</p><p class="" style="text-align: justify;">We could provide Clang a side table, via structured comments, to describe the unavailable selectors. That would let us at least give a better runtime error.</p><p class="" style="text-align: justify;">We could make <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> on a class give you the Swift 3 behavior, where it is implied on all of that class’s members. Sort of like how <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">public</span> <span class="pre">extension</span></code> makes all of the members inside the extension be public. That would make the splat-<code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code>-everywhere migration story less painful because of a much smaller “everywhere”. You would want this behavior in two major cases: When you’re migrating code from Obj-C to Swift and you want everything to be exposed to Obj-C, and when you’re migrating Swift 3 to Swift 4.</p><p class="" style="text-align: justify;">Requiring an explicit selector name if you write <code class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">@objc</span></code> would be too much boilerplate. Sometimes the default is ok, and sometimes you just don’t care.</p><p class="" style="text-align: justify;">Is there a problem that people know what <em class="">is</em> being exposed to Obj-C, but don’t know what <em class="">needs</em> to be exposed?</p></div><div class="section" id="argument-labels" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14.399999618530273px;"><h3 class="" style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;">Argument labels<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2017-01-04.html#argument-labels" title="Permalink to this headline" style="visibility: hidden; font-weight: bold; text-decoration: none; color: rgb(167, 206, 56); padding-left: 5px;"></a></h3><p class="" style="text-align: justify;">A bunch of changes in Swift 3 made argument labels not part of the tuple, which leaves a bunch of annoying special cases.</p><p class="" style="text-align: justify;">Let’s fix it. This seems like a starter proposal. We have a JIRA keyword for starter proposals, and a number of other starter proposals that we can let folks in the community pick up — although we do need to decide on a timeline, likely a month or two.</p><div class=""><br class=""></div><div class=""><div class="" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px;"><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://bugs.swift.org/issues/?jql=labels = StarterProposal" class="">https://bugs.swift.org/issues/?jql=labels%20%3D%20StarterProposal</a></div></div><div class=""><br class=""></div></div></div></body></html>