<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="">Thanks for the link, I'll definitely keep my eye on it, though since there are two large camps siding with either side, I don't see the harm making this proposal an optional warning of the compiler that would be off by default and those wanting to stay on the safe side would enable this and get a warning.<div class=""><br class=""></div><div class="">BTW another example of what this would prevent:</div><div class=""><br class=""></div><div class="">On OS X, all views (NSView) have a print(_:) method. So whenever you write within your code print("something"), it actually invokes the printing method (since its argument is AnyObject?) - if you indeed want to print something to the console, you need to use Swift.print("something") which is incredibly annoying mostly when you forget about this and all of sudden you get print dialogs instead of a log in the console.</div><div class=""><br class=""></div><div class="">Yes, it's shadowing, but with this one, you can't do anything about and there will always be cases of shadowing - the more dangerous when you don't know about them.</div><div class=""><br class=""></div><div class="">Krystof</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2016, at 6:32 AM, Félix Cloutier 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">That proposal might be one of the first early proposals to really get a lot of attention. My take out of the experience is that people (me included in this case) will yell very loudly if you try to enforce your coding standards through the compiler.<div class=""><br class=""></div><div class="">There is an <a href="https://github.com/realm/SwiftLint/issues/321" class="">open bug on SwiftLint</a> to add a rule that enforces using self to access member variables. It might be worth taking a look.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant-ligatures: normal; font-variant-position: normal; font-variant-caps: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 17 mai 2016 à 22:09:44, Krystof Vasa via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi there,<br class=""><br class="">I've been an OS X developer for over a decade now and was a huge fan of ObjC, implementing ObjC runtime into FreeBSD kernel as a intern at Cambridge University and my Masters thesis was a modular ObjC runtime that ran on Win 3.11. With the advance of Swift, it was clear to me, however, that this is a point to say goodbye to ObjC and move to Swift.<br class=""><br class="">And so, I've migrated all my projects over 5 months into Swift, which is over 200 KLOC of code, with one project being 90 KLOC. This has lead unfortunately to various hiccups due to bugs in Swift, Xcode, compiler, where I was unable to build a project for a month, etc. - I've filed 84 bug reports at <a href="http://bugreport.apple.com/" class="">bugreport.apple.com</a> over the past few months regarding developer tools (including Swift) and have begun closely watching the evolution of Swift.<br class=""><br class="">While I strongly disagree with the rejection of SE-0009, I understood the reasoning that it's a boilerplate to keep adding self. in front of all variables. I personally always refer to self when accessing instance variables (and methods), unless they are private variables starting with underscore. I know the underscore thing isn't very Swift-y, but on the other hand, reading the code you immediately know you are dealing with a private instance variable, not something local.<br class=""><br class="">This was until I spent 2 hours chasing a bug that was caused by the exact issue this proposal was trying to prevent. I was furious. <br class=""><br class="">a) When you read someone elses code and you see myVar.doSomething(), you assume it's refering to a local variable. Which is incredibly confusing, if this is an instance variable. Swift is all about compile-time checks and this is where it fails.<br class=""><br class="">b) If you indeed decide not to go with this proposal, please consider adding a warning option. When you take a look at LLVM warning options, I bet there would be a place for this. Let the user decide. I personally would immediately turn it on on all my projects. Don't make it an error, make it a warning.<br class=""><br class="">I speak to you as someone with quite a huge real-life experience with Swift, mainly in the last year - the question whether to force the reference to self is something that may be dividing the community, but I believe that most people with more developing experience would be all for this. At least as an option.<br class=""><br class="">Sincerely yours,<br class=""><br class="">Krystof Vasa<br class=""><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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<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>