[swift-evolution] Mutability inference

[Angelo Villegas]

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> 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> 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
>
> _______________________________________________
> 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/b10c3b75/attachment.html>