<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 Apr 20, 2016, at 11:16 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hello Swift community,</div><div class=""><br class="">The review of "SE-0068: Expanding Swift Self to class members and value types" begins now and runs through April 25. The proposal is available here:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md</a><br class=""></div></div></div></blockquote></div><div class=""><br class=""></div><div class=""><b class="">RELATED DISCUSSIONS</b></div><div class=""><br class=""></div><div class="">* <a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/15009" class="">Design Team feedback</a> on SE-0068</div><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708" class="">[Pitch] Adding a Self type name shortcut for static member access</a></div><div class=""><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/14445" class="">[Pitch] Rename `x.dynamicType` to `x.Self`</a></div><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/9059" class="">Making `.self` after `Type` optional</a></div><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/14173" class="">Remove the Need for 'self' to Access 'dynamicType'</a></div><div class=""><br class=""></div></div><div class=""><b class="">SHOULD .self BE REMOVED FROM TYPES</b></div><div class=""><b class=""><br class=""></b></div><div class="">Design team notes say:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">We have a proposal to remove </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">.self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> on types. One reason </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">.self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> exists is to avoid the mistake of writing </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">let</span> <span class="pre">x</span> <span class="pre">=</span> <span class="pre">Int</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> — the compiler will give you a weird type error later on in code if the value of </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">x</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> is what we today call </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">Int.self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> but you meant to call the </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">Int()</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.</span></div><div class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""><br class=""></span></div><div class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">Coming back to this proposal, if we removed </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">.self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> why would we want to add </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">.Self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">?</span></div></blockquote><div class=""><b class=""><br class=""></b></div><div class="">Background:</div><div class=""><ul class="MailOutline"><li class="">From Joe Groff: "`.self` is also a bit of load-bearing duct-tape that currently supports some other parsing aspects of Swift's syntax." </li><li class="">Jordan Rose adds, "Swift's type-checking engine is strong enough to merit not needing the redundant `.self` safety check." </li></ul></div><div class=""><br class=""></div><div class="">I personally like distinguishing `Type.self` from raw `Type` use for the reasons stated. This feature affirmatively prevents the use of `Typename` when `Typename()` is meant. In terms of this proposal, can this and should this be retained in the language but renamed from `self`? That would update the quiz to:</div><div class=""><br class=""></div><div class=""><pre class="" style="color: rgb(51, 51, 51); 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);"><span class="n">Self</span><span class="o" style="color: rgb(102, 102, 102);">.<runcible> // T.Type</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 // T.Type</span>
<span class="n">Self</span><span class="o" style="color: rgb(102, 102, 102);">.</span><span class="n">Self // T.Type.Type</span>
<span class="bp" style="color: rgb(0, 112, 32);">self</span><span class="o" style="color: rgb(102, 102, 102);">.<runcible> // == self</span></pre><div class="">Which reduces at least some of the confusion. The actual runcible name could be bikeshedded.</div></div><div class=""><br class=""></div><div class=""><b class="">IS `Self` THE RIGHT NAME? / </b><b class="">SHOULD `dynamicType` require `self`</b></div><div class=""><br class=""></div><div class="">I like `Self`. It is an existing keyword. It matches the approach used in protocols where `Self` is a placeholder for the type that conforms to that protocol. Under SE-0068, it refers to the dynamic type of the current instance. If it has to be a choice of one or the other, I'd prefer renaming `.self` and retaining `Self`. If `Self` is not the right name, I'd recommend either the `dynamictype` keyword and dropping the `self` prefix requirement <i class="">or</i> using a freestanding `dynamicType()` call. </div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">We have one keyword left in the language, </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">dynamicType</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">, which is camel cased. This proposal renames it to </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">Self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> instead.</span></div></blockquote><font color="#333333" face="DejaVu Sans, Arial, Helvetica, sans-serif" class=""><br class=""></font><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; 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 </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">dynamicType(_:)</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> does still allow for that function to be implemented using compiler magic.</span></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div style="text-align: justify;" class=""><font color="#333333" face="DejaVu Sans, Arial, Helvetica, sans-serif" class=""><br class=""></font></div><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">Another approach would be to introduce a new </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">dynamictype</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> keyword that doesn’t need to be accessed as a member of </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">, and keep </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">Self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> the way it is. </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">Self</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> should work in structs as a type alias.</span></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""><br class=""></span></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">Another perspective is that </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">.dynamicType</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> is just an implicitly synthesized property on all type.<br class=""></span><br class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class="">Subjectively, having </span><tt class="literal docutils" style="color: rgb(51, 51, 51); font-size: 1em; text-align: justify; background-color: rgb(226, 226, 226);"><span class="pre">dynamicType</span></tt><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; text-align: justify;" class=""> as a member feels weird.</span></blockquote><div class=""><b class=""><br class=""></b></div><div class="">If retained as a keyword, I believe it should be lowercased to `dynamictype`. This leaves two remaining outliers (`willSet` and `didSet`). If it is re-introduced as a stdlib function, it should be `dynamicType()`.</div><div class=""><br class=""></div><div class=""><b class="">------</b></div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">ORIGINAL DESIGN TEAM FEEDBACK</b></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 class="" style="font-size: 1.1em; font-weight: normal; color: rgb(12, 55, 98); margin-top: 30px;">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 class="" style="text-align: justify;"><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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">Quiz time! What do each of the permutations mean?</p><div class="highlight-python"><div class="highlight" style="background-color: rgb(238, 255, 204);"><pre class="" 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);"><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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" 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);">func dynamicType<T>(_: T) -> T.Type { }</pre></div><p class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class="" style="text-align: justify;">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 class=""><br class=""></div></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;"></div></div></body></html>