Mutability inference


(Thorsten Seitz) #1

I don’t see it as the machine dictating and the developer obeying but rather as a warning by the machine to the developer to check whether that really is what he intended. Instead of just changing the “let” to “var” it is equally possible that the code is to be changed such that the intended immutability is preserved.

-Thorsten

···

Am 25. Februar 2016 um 03:31 schrieb Darko Damjanovic via swift-evolution swift-evolution@swift.org:

If you want to be lazy about it, what about letting the compiler advice you? You could define every new variable as “var”, without thinking about it. And after you completed the implementation of the related scope, see what the compiler tells you. And just apply its advice.

Wouldn’t that be sufficient?
Hello Mathieu,

You are right, I work in a similar way currently. I have my personal rule to commit into Git 100% error and warning free. So I define every new variable as „let“ and if I get a compiler error I change it to "var“. So this is going on all day long - I define „let“ and often the compiler say’s „no - var!“ and I obey. (what else?) :slight_smile: But after doing this game a thousand times I got tired. Asking myself - well, if the compiler knows better anyway, why do I have to tell him all the time? I fully understand the advantages of immutability (that’s why at first „let“ and not „var“) but meanwhile it just feels like boilerplate repetitive code and the machine dictates it to me anyway.