[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