[swift-evolution] Mutability inference

[Jordan Rose]

> On Feb 24, 2016, at 18:26 , Darko Damjanovic via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> The problem with this approach is that you’re favoring writability of the code at the expense of readability/maintainability.  
> 
> 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.

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 not obvious, you should write it even if the compiler can figure it out for you.

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.

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.

(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.)

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160224/c3cd9d61/attachment.html>