<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 24, 2016, at 18:26 , Darko Damjanovic 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 class=""><blockquote type="cite" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The problem with this approach is that you’re favoring writability of the code at the expense of readability/maintainability. <br class=""></blockquote><br style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">You are right, it would. On the other side - the same is happening already with type inference, right? And to an even greater extent - because: isn't the very type even more important on first sight then the mutability? But it turns out not to be a problem because of the compilers type safety. It doesn't matter what you do with it, you can rest assured that the compiler will take care not to misuse the type in any way. And this is not the only "magic" which is taken care of by the compiler, think about copy-on-write for value types or ARC. All of this is „hidden“ and not clear on first sight.</span><br style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></div></blockquote></div><br class=""><div class="">I'm not particularly happy with this view of type inference. I think the reason it's okay to infer the type of a binding is because it's obvious from context (i.e. the expression). If it's <i class="">not</i> obvious, you should write it even if the compiler can figure it out for you.</div><div class=""><br class=""></div><div class="">Ideally, code should be written for humans to read, not for compilers to check. I'd like to be able to read a commit and know what it's doing without having to build it.</div><div class=""><br class=""></div><div class="">I'm against "implicit var" on these grounds because it turns out it's much simpler to "look at code and know what it does" if a local variable has the same value the whole time it's used, at least for me. "Implicit var" for locals is the same as not having 'let', because as we've seen in C most people won't bother to use 'let' and its restrictions when it's not the default.</div><div class=""><br class=""></div><div class="">(I'm against "implicit let" for the JavaScript/Python reason of it being too easy to accidentally create a new binding when you meant to modify something in scope or vice versa.)</div><div class=""><br class=""></div><div class="">Jordan</div></body></html>