[swift-evolution] Mutability inference

Taras Zakharko taras.zakharko at googlemail.com
Thu Feb 25 05:20:22 CST 2016


> On 25 Feb 2016, at 10:41, Darko Damjanovic via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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. 

I don’t think you should be looking forward to it :) If the compilers ever evolve that far, most programmers might just become unemployed. 

t.

> 
> 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
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list