[swift-evolution] Mutability inference
Developer
devteam.codafi at gmail.com
Wed Feb 24 21:28:22 CST 2016
It is an interesting idea all the same, and it would be cool to see it applied in a language like ML that encourages large amounts of let-bound constants and statements.
~Robert Widmann
2016/02/24 22:21、Darko Damjanovic <darkodamjanovic at me.com> のメッセージ:
> Hello Robert,
>
> that's great, getting so much highly accurate input about this theme makes me understand better the advantages of the current solution. I appreciate that. Thanks.
>
> - Darko
>
>
>
>> Am 25.02.2016 um 03:59 schrieb Developer <devteam.codafi at gmail.com>:
>>
>> But that's the thing: I don't wish to encourage mutability through the omission of a keyword. (I don't wish to encourage mutability in any case, but that's beside the point!). Your point about types being implicit is entirely different. If type inference does its job, there is no way to apply a term of a certain type as an argument to a function expecting a different type. The same is not true of this scheme of inference. Because I cannot ask swift to guarantee that terms are mutable or immutable, or specify that a function should be pure, I have no immediate guarantees about the mutability of my variables at first glance. That's a level of uncertainty about my code I wouldn't wish to have for any amount of keystroke savings.
>>
>> ~Robert Widmann
>>
>> 2016/02/24 21:34、Darko Damjanovic <darkodamjanovic at me.com> のメッセージ:
>>
>>> Hello Robert,
>>>
>>> I am doing most of the time application development, so I do not need to take care _so_ much about it. But I assume in case of writing lib’s for external usage this could be important, yes. But If you want to explicitly declare immutability just write „let“. Nothing hinders you, right?
>>>
>>> - Darko
>>>
>>>
>>>> Am 24.02.2016 um 23:52 schrieb Developer <devteam.codafi at gmail.com>:
>>>>
>>>> -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> のメッセージ:
>>>>
>>>>> –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> 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
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160224/6d4d67ef/attachment.html>
More information about the swift-evolution
mailing list