[swift-evolution] Mutability inference

[Darko Damjanovic]

Could you give some examples about such bugs? Thanks.


> Am 25.02.2016 um 00:42 schrieb Haravikk via swift-evolution <swift-evolution at swift.org>:
> 
> I’m a -1 as well; while I do find the warnings annoying sometimes when a declare a var that I haven’t modified yet, I’d rather have them than not. If there were an option to not decide then developers could end up using it by default just because it’s easier, which could allow a slew of bugs to creep in that Swift currently protects against.
> 
>> On 24 Feb 2016, at 22:52, Developer via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> -1.  In addition, it would imply that all variables are mutable "by default" (a la Python), because all it would take to change an implicit let to an implicit var would be an accidental extra assignment in another branch somewhere.
>> 
>> ~Robert Widmann
>> 
>> 2016/02/24 16:44、Riley Avron via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
>> 
>>> –1. This would make reading and maintaining code appreciably harder for a trivial reduction in character count when writing code. 
>>> 
>>> Riley
>>> 
>>> On 23 February 2016 at 23:06, Darko Damjanovic via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160225/c643e3fb/attachment.html>