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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Darko_Damjanovic]

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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Taras_Zakharko1 (Taras Zakharko)]

Explicit variable-level mutability declaration is one of the strong points of Swift. Nothing is gained by saving on ‘var’ or ‘let’. I strongly doubt that removing mutability declarations would improve the speed of writing (its just 3 extra characters). At the same time, these declarations force you to think about the structure of your algorithms and your code.

— Taras

···

On 25 Feb 2016, at 04:24, Angelo Villegas via swift-evolution <swift-evolution@swift.org> wrote:

Writability over maintainability? I'm going to vote against this, so -1.
On Thu, 25 Feb 2016 at 10:43 AM Craig Cruden via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
There is quite a bit of difference between type inference and mutable / immutable inference.

Types are important and type safety is important - as it allows the compiler to check during compile time. Type inference does not take away from this - the compiler still checks that a variable / constant is the same type wherever it is used.

It does not matter whether variable “a” is a string. It matters that if “a” is a string, it is always a string.

I do think that “let” is unfortunately scattered throughout the code which makes things like pattern matching less focused/clear - and would appreciate if let is inferred in those circumstances.

“var” should never be inferred.

As far as “let x = …" being inferred, I don’t see much benefit — and quite a bit of risk of variables bleeding unintentionally between different scopes. (let is also pretty standard in math).

> On 2016-02-25, at 9:26:18, Darko Damjanovic via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> Hello Chris,
>
>> The problem with this approach is that you’re favoring writability of the code at the expense of readability/maintainability.
>
> You are right, it would. On the other side - the same is happening already with type inference, right? And to an even greater extent - because: isn't the very type even more important on first sight then the mutability? But it turns out not to be a problem because of the compilers type safety. It doesn't matter what you do with it, you can rest assured that the compiler will take care not to misuse the type in any way. And this is not the only "magic" which is taken care of by the compiler, think about copy-on-write for value types or ARC. All of this is „hidden“ and not clear on first sight.
>
>> The major win of having let and var in the code is that it expresses the intention of what is happening: when you see a “let x = …” you know that x will never be changed.
>
> Yes, but now it's not _that_ important anymore, because the compiler can take care of it. Same as with type inference, COW and ARC. The compiler knows better - meanwhile. And same as with type inference you still could write "let" and "var" if it is important in the current context. And if you explicitly want the reader of the code to know about it on first sight.
>
> But I have to admit that making both „let“ and „var" optional without any substitute could lead to problems. Like David Smith wrote:
>
> "it becomes easy to accidentally introduce a new variable rather than refer to an existing one"
>
> Stephen Celis gives a very good solution for this:
>
> let a: String = "string"
> b: String = "string" // short-hand avoids let
> b := "string" // shorter-hand
>
> I like this. The obvious other solution would be a new keyword (don't like this).
>
> It would not be of a big problem for me if it stay's like it is currently, not at all. It just feels like it's time to move on because the compiler get's smarter and smarter. It was a similar situation with ARC a few years ago if I remember it correctly. At first it was just an additional help for the developer (like the mutability warnings currently) but later it turned out that the compiler already surpasses the developer.
>
> I am new to this list, so sorry about "jumping around" with the proposal. But currently I have no one else to discuss this because I am the only Swift developer in my company. :) Please let me know if this kind of discussion is not appropriate on this list. Thanks.
>
> - Darko
>
>
>
>
>> Am 24.02.2016 um 19:40 schrieb Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>>:
>>
>>
>>> On Feb 23, 2016, at 11:06 PM, Darko Damjanovic via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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?
>>
>> The problem with this approach is that you’re favoring writability of the code at the expense of readability/maintainability. The major win of having let and var in the code is that it expresses the intention of what is happening: when you see a “let x = …” you know that x will never be changed.
>>
>> -Chris
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Taras_Zakharko]

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.

···

On 25 Feb 2016, at 10:41, Darko Damjanovic via swift-evolution <swift-evolution@swift.org> wrote:

Nevertheless thanks to all of you for the great input.

Br,
Darko

Am 25.02.2016 um 03:37 schrieb Brent Royal-Gordon <brent@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[codafi (Robert Widmann)]

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@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@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@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@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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution