<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="">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 yesterday's discussion.</div><div 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=""><br class=""></div><div class=""><div class="section" id="se-0068-expanding-swift-self-to-class-members-and-value-types" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">SE-0068: Expanding Swift Self to class members and value types<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-04-20.html#se-0068-expanding-swift-self-to-class-members-and-value-types" 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 style="text-align: justify;" class=""><a class="external reference" href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md" style="font-weight: bold; text-decoration: none; color: rgb(137, 38, 1);">https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md</a></p><p style="text-align: justify;" class="">We have one keyword left in the language, <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamicType</span></tt>, which is camel cased. This proposal renames it to <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self</span></tt> instead.</p><p style="text-align: justify;" class="">In a static function today, <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">self.dynamicType</span></tt> will give you a metatype but the non-member <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self</span></tt> will not. The most useful reason to reference it is to call an initializer. It makes accessing the metatype weirder. It’s not <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self.Type</span></tt>; that’s a type — you have to spell it <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self.type</span></tt>.</p><p style="text-align: justify;" class="">Quiz time! What do each of the permutations mean?</p><div class="highlight-python"><div class="highlight" style="background-color: rgb(238, 255, 204); background-position: initial initial; background-repeat: initial initial;"><pre style="overflow-x: auto; overflow-y: hidden; border: thin dotted rgb(12, 55, 98); margin-top: 0px; margin-bottom: 12px; padding: 0.8em; background-color: rgb(240, 240, 240);" class=""><span class="n">Self</span><span class="o" style="color: rgb(102, 102, 102);">.</span><span class="n">self</span>
<span class="bp" style="color: rgb(0, 112, 32);">self</span><span class="o" style="color: rgb(102, 102, 102);">.</span><span class="n">Self</span>
<span class="n">Self</span><span class="o" style="color: rgb(102, 102, 102);">.</span><span class="n">Self</span>
<span class="bp" style="color: rgb(0, 112, 32);">self</span><span class="o" style="color: rgb(102, 102, 102);">.</span><span class="n">self</span>
</pre></div></div><p style="text-align: justify;" class="">The number of capital letters gives you the level of meta-ness. This is very subtle, which is probably not a good thing.</p><p style="text-align: justify;" class="">Another approach would be to introduce a new <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamictype</span></tt> keyword that doesn’t need to be accessed as a member of <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">self</span></tt>, and keep <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self</span></tt> the way it is. <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self</span></tt> should work in structs as a type alias.</p><p style="text-align: justify;" class="">Why don’t we turn this into a standard library function? It’s not something you need so often that the member access is very valuable. Putting it in the standard library as <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamicType(_:)</span></tt> does still allow for that function to be implemented using compiler magic.</p><div class="highlight-python"><pre style="overflow-x: auto; overflow-y: hidden; border: thin dotted rgb(12, 55, 98); margin-top: 0px; margin-bottom: 12px; padding: 0.8em; background-color: rgb(240, 240, 240);" class="">func dynamicType<T>(_: T) -> T.Type { }</pre></div><p style="text-align: justify;" class="">We have a proposal to remove <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.self</span></tt> on types. One reason <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.self</span></tt> exists is to avoid the mistake of writing <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">let</span> <span class="pre">x</span> <span class="pre">=</span> <span class="pre">Int</span></tt> — the compiler will give you a weird type error later on in code if the value of <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">x</span></tt> is what we today call <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Int.self</span></tt> but you meant to call the <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Int()</span></tt> initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.</p><p style="text-align: justify;" class="">It’s weird that you can use the metatype directly to construct something or to do member access, but you can’t access it as a bare value.</p><p style="text-align: justify;" class="">Coming back to this proposal, if we removed <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.self</span></tt> why would we want to add <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.Self</span></tt>?</p><p style="text-align: justify;" class="">If you have a variable whose value is a metatype, you also keep its name in lower case. So <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Self</span></tt> makes a little less sense from that aspect too.</p><p style="text-align: justify;" class="">Another perspective is that <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.dynamicType</span></tt> is just an implicitly synthesized property on all type.</p><p style="text-align: justify;" class="">We do have other keywords that follow the dot on types, <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Int.Type</span></tt> and <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">Fooable.Protocol</span></tt>, so this isn’t the only thing. Those things are magic nested types.</p><p style="text-align: justify;" class="">Subjectively, having <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">dynamicType</span></tt> as a member feels weird.</p><p style="text-align: justify;" class="">If <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.self</span></tt> goes away, the four-self example above is simplified, and <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.Self</span></tt> doesn’t make sense anymore. There’s also the difference that <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">.Self</span></tt> would be a runtime thing.</p></div><div class="section" id="what-to-do-about-optional-requirements" style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"><h3 style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;" class="">What to do about optional requirements<a class="headerlink" href="file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-04-20.html#what-to-do-about-optional-requirements" 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 style="text-align: justify;" class=""><a class="external reference" href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046" style="font-weight: bold; text-decoration: none; color: rgb(137, 38, 1);">http://thread.gmane.org/gmane.comp.lang.swift.evolution/14046</a></p><p style="text-align: justify;" class="">People commonly ask why <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">optional</span></tt> only works on Objective-C protocols, and the responses they get are usually that in Swift code you should reshape your protocols. As a starting assumption, we’re not making <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">optionl</span></tt> work in Swift. So what do we do about this as part of the interoperability code?</p><p style="text-align: justify;" class="">People do write these, but it’s often because they’re writing a delegate protocol and they’re following the example of Cocoa frameworks.</p><p style="text-align: justify;" class="">Roughly three things we can do:</p><ol class="arabic simple" style="padding-left: 20px; list-style-position: initial; list-style-image: initial;"><li style="line-height: 1.3;" class="">Rename it to make it clearly an Objective-C interop feature. We could also forbid you actually spelling it in Swift code. That doesn’t work well because it breaks your ability to write code in Swift that has Objective-C clients — those clients won’t get the default implementation from the extensions like you would use with Swift clients instead of creating optional requirements.</li><li style="line-height: 1.3;" class="">Modeling optional requirements as a function of optional type such as <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">((A,</span> <span class="pre">B)</span> <span class="pre">-></span> <span class="pre">C)?</span></tt> doesn’t work well. For example, properties can have optional type and they can be optional requirements, so you would end up having to deal with a lot of extra complexity due to double-optionals and likely want better code completion so you could type it all out.</li><li style="line-height: 1.3;" class="">You force the default implementation to be visible from all callers, and you do the dispatch at the call site. The only advantage of this is that it takes optional requirements out of the language entirely. If you wanted to implement the (somewhat common) pattern of checking whether a type implements an optional requirement, you would have to use a <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">respondsToSelector</span></tt> check.</li></ol><p style="text-align: justify;" class="">The best pattern we’ve seen for checking conformance and using different code paths based on that is to use finer-grained protocols. (But there are still issues with organizing your code that way.)</p><p style="text-align: justify;" class="">The caller default (#3) is really the only way to get optional requirements out of the type system. The weird code path in the compiler here is the same as the weird code path as we have in <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">AnyObject</span></tt>. But it doesn’t look like we’re going to be able to do that.</p><p style="text-align: justify;" class="">We can rename this as <tt class="literal docutils" style="background-color: rgb(226, 226, 226); font-size: 1em;"><span class="pre">objcoptional</span></tt> or possibly demote it to an attribute.</p></div></div><div class=""><div class="bottomnav" style="background-color: rgb(238, 238, 238); color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"></div></div><div class=""><div class="bottomnav" style="background-color: rgb(238, 238, 238); color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif;"></div></div></body></html>