<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>As I said previously, same for me. But even if that weren't the case; I find it difficult to defend the readability of a language's feature uniquely by an editor's syntax highlighting.<br></div><div><br></div><div>The proposal here had the same objectives (but is more elegant) to what created conventions like Hungarian notation where m_ prefixes member variables.</div><div><br><div><br><br>Sent from my iPhone</div>On 05 Dec 2015, at 08:49, Tyler Cloutier <<a href="mailto:cloutiertyler@aol.com">cloutiertyler@aol.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>I'm not sure how many Swift users this effects, but I'm colorblind and I really struggle with the local vs properties syntax coloring.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Tyler<br><br><div><br></div></div><div><br>On Dec 4, 2015, at 3:37 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br><br></div><blockquote type="cite"><div>
<title></title>
<div>Do you use Xcode to edit Swift? Xcode gives a color to properties/methods and doesn't color local variables/arguments. Is that not sufficient to distinguish this? In my experience the color is actually better than seeing the explicit `self.` because the color can be recognized faster than reading a word, and is visible in a high-level "squint" view of the function.<br></div>
<div> </div>
<div>If you're using another editor, well, my best suggestion there is to look into what it would take to integrate SourceKit functionality into that editor for more intelligent coloring :)<br></div>
<div> </div>
<div>-Kevin</div>
<div> </div>
<div>On Fri, Dec 4, 2015, at 03:29 PM, Colin Cornaby wrote:<br></div>
<blockquote type="cite"><div>+1<br></div>
<div> </div>
<div>I've had a lot of weird things happen that I've traced to mistakes in properties having the same name as function arguments. I've hardly ever had this issue in modern Obj-C.<br></div>
<div> </div>
<div>I'm a little more ok with functions not needing self as it's less likely for those to shadow something like an argument, but I guess the consistency would be nice too.<br></div>
<div><div> </div>
<div>On Dec 04, 2015, at 01:20 PM, David Hart <<a href="mailto:david@hartbit.com">david@hartbit.com</a>> wrote:<br></div>
</div>
<div><blockquote type="cite"><div><div><span>I don't understand the reasoning behind removing the need to access instance properties and functions using self. Swift has always seemed to prefer readability to brevity and the feature makes the distinction between local and instance variables/functions crystal clear. Any good reason I shouldn't go on with the proposition?<br><br>Just as example, my proposition makes the following piece of code illegal:<br><br>```<br>struct FooBar {<br> var foo: String = "foobar"<br><br> func bar() {<br> print(foo) // compiler error<br> print(self.foo) // compiler happy<br> }<br><br> func bar2() {<br> bar() // compiler error<br> self.bar() // compiler happy<br> }<br>}<br>```<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div>
</div>
</blockquote></div>
<div><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/0a622f8228c82468856954859f7b17f72f52131d15aba0dfe2aad604cdc7f5e2/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e49564e455e4759687670396f624e6835416971525551795265655666357a75567f4549313141795257566c4869564e454f4879694a657774705573414d22364e464439346e623245307d223247435f6f46574d2232453767457731363154795d22324d2236445c4936694d2236457462364d465e6448396d6a7342614a5f4565766a533559394731735d474848424646687250576636333d673d42597735747851765b434d22324b405560747d654154455c4a576561627d22324263534c443833413d414b624a79376671636d4a7666314d23344d23344/open"><br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=DOmV4Qxg-2B1XOnX4CfTyH3sCllXs7myBcgXMCpdkqNW3HUZ5zKzBNdYSBpsCB5goig6QGo8JDULLi-2B2gAGpueq1qjVsIYw1P82pcrA321BHUwYYtZ3r4m8LlpX11HSErkz2S-2BXZZGPzOS4BfVaWhrGrL-2FDXt0Zj3k-2FxXy6GGEXU7Js9vGt6ZURRIceBUv4T0-2F-2B6xN-2Fg61syTTdDycKq14HsB9xhc3oKFaJgmZraomwz4-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43hXwizS3O2z60WweqomIrdgsctpUi18HdSP3R83d10uuv683SpemES7akv06r4vle7-2FqUBy4a0QKuj9QBTbfBiWasrjbgjlm2fyqHX8eate5feoqf94W77zxgWr4AlsDBQyL3jo7-2FxtYx4oorxcuGQ88h9DnFkOXLCtXQZGmqpFW0MdX55tmaUrLRn31NIlBOu8vTYVB3WIc0o2WXry8gVo-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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>