[swift-evolution] Mutability inference

Wed Feb 24 23:54:05 CST 2016

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 at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto: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 <mailto:clattner at apple.com>>:
> >>
> >>
> >>> On Feb 23, 2016, at 11:06 PM, 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?
> >>
> >> 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 <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
> 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/1bbff91a/attachment.html>