<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><div id="bloop_customfont" style="margin: 0px;">Agreed – there are a few different disadvantages to adopting this new behaviour that aren’t discussed or mentioned at all. Especially considering the confusion from newcomers who <i>do</i> try to use the `let a = self.a` shortcut on value types…</div><div id="bloop_customfont" style="margin: 0px;"><br></div><div id="bloop_customfont" style="margin: 0px;">Ash</div><div><br></div></div><p class="airmail_on">On December 15, 2015 at 5:09:40 PM, Preston Sumner via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div><br>I suspect people would use local variable boilerplates to circumvent mandatory self, as they do in Objective-C.<br><br>let a = self.a<br>let b = self.b<br>let c = self.c<br><br>// Actually do stuff with a, b, and c.<br><br>Preston<br><br>> On Dec 15, 2015, at 1:03 PM, sune.foldager--- via swift-evolution <swift-evolution@swift.org> wrote:<br>> <br>> Personally, I am against using mandatory self. I have coded a lot of Python, and I find it quite annoying to have to type (and read) “self.” everywhere. It’s a balance, of course:<br>> <br>> “self.” everywhere means you can see what’s an instance member and what’s a local variable. That’s generally a good thing. But it also means a lot of filler text in your code, which makes reading and writing slower. That’s not so good. It’s a balance, and in this case my experience from C# (and, as mentioned, Python) is that I much prefer C#’s non-mandatory use of “this”/“self".<br>> <br>> I see that this proposal is going to be reviewed as SE-0009, and I am a bit concerned that not all arguments are being considered because of the contents of the proposal text: The only counter argument mentioned in the proposal has to do with capturing semantics in closures. This is fine, but why isn’t the counter argument of verbosity being mentioned? This has been brought up on the list as well.<br>> <br>> Also, the “Community Responses” section exclusively lists positive feedback. Is that how it’s supposed to be with the SE process? If not, where are the arguments from people who are -1 on the proposal?<br>> <br>> I really hope the review team considers:<br>> - The negative responses on this list as well. Also consider that many Swift developers are not on this list; I doubt it’s representative, either, being dominated by “language interested” developers.<br>> - The rather large amount of changes to existing code required.<br>> <br>> -Sune<br>> <br>> _______________________________________________<br>> swift-evolution mailing list<br>> swift-evolution@swift.org<br>> https://lists.swift.org/mailman/listinfo/swift-evolution<br><br>_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></body></html>