[swift-evolution] Mutability inference

[Darko Damjanovic]

Hello Mathieu,

> 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?


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?) :) 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.

- Darko




> Am 24.02.2016 um 09:37 schrieb Mathieu Godart <m at godart.co>:
> 
> Interesting idea. I like to be able to be lazy! 😊 
> 
> But I agree with David. So, we could imagine a new keyword, like "varlet" or "autovar", or whatever to avoid confusion between declaration and assignment... But this would impact drastically the readability. The compiler would know, but not the human reader. And this loss in readability would be very impactful, imho. The mutability character carries a lot of information. 
> 
> 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?
> 
> Mathieu Godart
> 
> PS : This is my first post on this mailing list. So, hello the Swift community!
> 
> 
> 
>> Le 24 févr. 2016 à 08:10, David Smith via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> One tricky thing with languages like this (javascript, for example) is that it becomes easy to accidentally introduce a new variable rather than refer to an existing one.
>> 
>>   David
>> 
>>> On Feb 23, 2016, at 11:06 PM, Darko Damjanovic via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> In the current Swift version the compiler is warning me if a variable is never written to and therefore should be a "let" constant. So now the compiler knows best if "let" or "var" should be applied. During writing code I experience repetitive hints about using "let" or "var" so why do I have to declare it all the time by myself if the compiler anyway knows best?
>>> 
>>> My proposal would be to make the declaration of "let" and "var" optional.
>>> 
>>> Example:
>>> x = 0 // <- implicitly declared as "var x" because later was written to, no need to declare it manually
>>> x = 5  
>>> 
>>> Example:
>>> y = 0 // <- implicitly declared as "let y" because later was not written to
>>> print(y) 
>>> 
>>> Example Optional Binding:
>>> if index = myArray.indexOf("A") {
>>>   print(index) // here it's clear that index can be "let index"
>>> }
>>> 
>>> etc...
>>> 
>>> This would _not_ mean to disallow or remove the "var and "let" mutability declarations - just to make them optional. If I still want to write it to make it clear just by reading thru the code then this is ok. But I can omit "var and "let" if I want -  why bother about it at all if I can go sure that the compiler is already doing the best?
>>> 
>>> Another option (if this is "too much" change) would be to just make "let" optional and "var" still should be explicitly written. So "let" would be the default and if I want mutability I have explicitly declare it as "var". This is already the rule for function parameters.
>>> 
>>> Kind regards,
>>> Darko Damjanovic-Lichtfuss
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution