<div dir="ltr">David,<div><br></div><div>I disagree that your two examples don't tell us much.</div><div><br></div><div><div style="font-size:12.8px"><font face="Menlo">foobar({</font></div><div style="font-size:12.8px"><font face="Menlo"><span style="white-space:pre-wrap"> </span>print(self.description)</font></div><div style="font-size:12.8px"><font face="Menlo">})</font></div></div><div style="font-size:12.8px"><font face="Menlo"><br></font></div><div style="font-size:12.8px"><font face="Menlo">This tells us that self will be captured by the closure, and reminds us that if that might create a retain cycle, to avoid memory leaks we need to add [weak self] or [unowned self] at the beginning of the closure.</font></div><div style="font-size:12.8px"><font face="Menlo"><br></font></div><div style="font-size:12.8px"><div style="font-size:12.8px"><font face="Menlo">barfoo({</font></div><div style="font-size:12.8px"><font face="Menlo"><span style="white-space:pre-wrap"> </span>print(description)</font></div><div style="font-size:12.8px"><font face="Menlo">})</font></div><div style="font-size:12.8px"><font face="Menlo"><br></font></div><div style="font-size:12.8px"><font face="Menlo">This tells us that we don't need to worry about self being captured in the closure because the compiler would force us to add self if anything that caused it to be captured were used in the closure.</font></div><div style="font-size:12.8px"><font face="Menlo"><br></font></div><div style="font-size:12.8px"><font face="Menlo">This is very helpful information to me, and information that would stand out less if I got used to seeing self everywhere, which is what your proposal would force.</font></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 6, 2015 at 6:10 PM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Nick,<div><br></div><div>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><br></div><div>If we use the <font face="Menlo">try</font> keyword as an example:</div><div><br></div><div><font face="Menlo">try foobar()</font></div><div><font face="Menlo">barfoo()</font></div><div><br></div><div>If the previous lines of code compile without error, we know without a shadow of a doubt that <font face="Menlo">foobar</font> is a throwing function and that <font face="Menlo">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><br></div><div>Now if we go back to the example of self in closures:</div><div><br></div><div><font face="Menlo">foobar({</font></div><div><font face="Menlo"><span style="white-space:pre-wrap"> </span>print(self.description)</font></div><div><font face="Menlo">})</font></div><div><br></div><div>The <font face="Menlo">self</font> keyword in the previous lines of code does not tell us anything at all:</div><div><br></div><div><ul><li><font face="Menlo">self</font> might have been forced by the compiler to warn us.</li><li><font face="Menlo">self</font> might have been a programmer choice if the closure was non-escaping.</li></ul><div><br></div></div><div>And the reverse:</div><div><br></div><div><div><font face="Menlo">barfoo({</font></div><div><font face="Menlo"><span style="white-space:pre-wrap"> </span>print(description)</font></div><div><font face="Menlo">})</font></div></div><div><font face="Menlo"><br></font></div><div>This also does not tell us much:</div><div><br></div><div><ul><li>The closure might be non-escaping.</li><li><font face="Menlo">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><br></div><div>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><br></div><div>With the proposition, <font face="Menlo">self</font> gets some meaning back: it indicates which are local and which are instance properties.</div><div><br></div><div>David.</div><div><br></div></div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On 06 Dec 2015, at 23:55, Nick Shelley via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">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><div><br></div><div>I can't seem to find an official Apple Swift style guide, but github's (<a href="https://github.com/github/swift-style-guide" target="_blank">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><div class="gmail_quote">On Sat, Dec 5, 2015 at 3:16 AM, Yichen Cao <span dir="ltr"><<a href="mailto:ycao@me.com" target="_blank">ycao@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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><div>
<br><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">Yichen</span>
</div>
<br><div><blockquote type="cite"><div>On Dec 5, 2015, at 18:11, <a href="mailto:swift-evolution-request@swift.org" target="_blank">swift-evolution-request@swift.org</a> wrote:</div><br><div><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">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"> </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">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"><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"> instance properties and functions (David Hart)</span></div></blockquote></div><br></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43hXwizS3O2z60WweqomIrdh885WGIgW1Y9cOEYBC1Bdi4-2FlEXwKeFNR3ZjPNv-2Fo5F3OuL0oC2ftKbmmTWUPpZLsAdq6UMl0r0L9zFFO81EA5WQ-2F3Xkq6HQTFaQHbi9LYhCS8cJgXeLZN8nJshdFpWLo0oUypEwbdCN58u7KsSJhjqRAJLcUgz8zCtGMBYNIONMi27hfFM88sKE7koZLG9Io-3D" alt="" width="1" height="1" border="0" style="min-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">
_______________________________________________<span class=""><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div>