[swift-evolution] Mutability inference

[Darko Damjanovic]

Hello Gordon,

so what you basically are saying is that the developer still can be smarter then the compiler in this regards. In this case - yes, it would be better to leave it as it is currently. I was not aware of this viewpoint. It seemed to me that the current warnings are already the best possible solution anyway. 

In this case my proposal is just to early. Maybe the compiler will evolve in the future in such a way that also immutability/mutability can be better done by the compiler then by the developer. 

Nevertheless thanks to all of you for the great input. 

Br,
Darko



> Am 25.02.2016 um 03:37 schrieb Brent Royal-Gordon <brent at architechies.com>:
> 
>> 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“.
> 
> I think the intention is that, before you change it to `var`, you should examine your code and see if there's a way you could write it that would allow it to remain a `let`. Could you assign it to a new constant instead of changing the old variable? Could you use a nonmutating operation instead of a mutating one? It's not that you *have* to take the nonmutating option—`var`s exist in Swift because they're perfectly appropriate in many cases—but if you try to turn `var`-based code into `let`-based code, the `let`-based version is often better.
> 
> -- 
> Brent Royal-Gordon
> Architechies
>