[swift-evolution] Mutability inference

[Craig Cruden]

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 at 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 at apple.com>:
>> 
>> 
>>> 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?
>> 
>> 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution