<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="">Hi Nick,<div class=""><br class=""></div><div class="">I understand the quote "This makes the capturing semantics of self stand out more in closures”, but this is a very weak statement in Swift for me. Let me try to explain.</div><div class=""><br class=""></div><div class="">If we use the <font face="Menlo" class="">try</font> keyword as an example:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">try foobar()</font></div><div class=""><font face="Menlo" class="">barfoo()</font></div><div class=""><br class=""></div><div class="">If the previous lines of code compile without error, we know without a shadow of a doubt that <font face="Menlo" class="">foobar</font> is a throwing function and that <font face="Menlo" class="">barfoo</font> does not throw. The compiler will not compile the first line without the keyword and would not allow it in on the second line.</div><div class=""><br class=""></div><div class="">Now if we go back to the example of self in closures:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">foobar({</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>print(self.description)</font></div><div class=""><font face="Menlo" class="">})</font></div><div class=""><br class=""></div><div class="">The <font face="Menlo" class="">self</font> keyword in the previous lines of code does not tell us anything at all:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class=""><font face="Menlo" class="">self</font> might have been forced by the compiler to warn us.</li><li class=""><font face="Menlo" class="">self</font> might have been a programmer choice if the closure was non-escaping.</li></ul><div class=""><br class=""></div></div><div class="">And the reverse:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">barfoo({</font></div><div class=""><font face="Menlo" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>print(description)</font></div><div class=""><font face="Menlo" class="">})</font></div></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">This also does not tell us much:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">The closure might be non-escaping.</li><li class=""><font face="Menlo" class="">description</font> might be referring to a local variable (which we missed the declaration) shadowing the instance property in an escaping closure.</li></ul><div class=""><br class=""></div><div class="">In both of these last examples, we can’t tell by having a quick look at the code at the point of call if we should really be careful about memory or not.</div><div class=""><br class=""></div><div class="">With the proposition, <font face="Menlo" class="">self</font> gets some meaning back: it indicates which are local and which are instance properties.</div><div class=""><br class=""></div><div class="">David.</div><div class=""><br class=""></div></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 06 Dec 2015, at 23:55, Nick Shelley 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=""><div dir="ltr" class="">I like that self is only required in closures because it serves as a good reminder that there are memory and safety implications with using self in a closure, such as creating retain cycles or having the closure run after self has been deallocated.<br class=""><div class=""><br class=""></div><div class="">I can't seem to find an official Apple Swift style guide, but github's (<a href="https://github.com/github/swift-style-guide" class="">https://github.com/github/swift-style-guide</a>) suggests only using self in closures with the rationale: "This makes the capturing semantics of self stand out more in closures, and avoids verbosity elsewhere."</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Dec 5, 2015 at 3:16 AM, Yichen Cao <span dir="ltr" class=""><<a href="mailto:ycao@me.com" target="_blank" class="">ycao@me.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Teaching wise, its much less confusing for self to be required so students don't mix up instance properties and local vars. Especially when self is required in closures, it confuses students. If self is mandatory for all instance properties, it would be so much clearer and much easier to read.<br class=""><div class="">
<br class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; float: none; display: inline !important;" class="">Yichen</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2015, at 18:11, <a href="mailto:swift-evolution-request@swift.org" target="_blank" class="">swift-evolution-request@swift.org</a> wrote:</div><br class=""><div class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">Re: Proposal: Re-instate mandatory self for</span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px" class=""> </span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class="">accessing</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important" class=""> instance properties and functions (David Hart)</span></div></blockquote></div><br class=""></div><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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43hXwizS3O2z60WweqomIrdh885WGIgW1Y9cOEYBC1Bdi4-2FlEXwKeFNR3ZjPNv-2Fo5F3OuL0oC2ftKbmmTWUPpZLsAdq6UMl0r0L9zFFO81EA5WQ-2F3Xkq6HQTFaQHbi9LYhCS8cJgXeLZN8nJshdFpWLo0oUypEwbdCN58u7KsSJhjqRAJLcUgz8zCtGMBYNIONMi27hfFM88sKE7koZLG9Io-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>