[swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching

[Ilya Belenkiy]

+1 on all accounts

On Fri, Jan 29, 2016 at 3:21 AM Ondrej Barina via swift-evolution <
swift-evolution at swift.org> wrote:

> +1
> Ondrej
>
> On Fri, Jan 29, 2016 at 8:14 AM, Taras Zakharko via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> A very reasonable decision! It is also good to know that accepted
>> proposals are not “absolute” but will be reviewed again if  necessary.
>>
>> — Taras
>>
>> On 29 Jan 2016, at 07:20, Paul Cantrell via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> +3 from me — one for each of the conclusions. This sounds exactly right.
>>
>> If I understand correctly, we now alllmost have a nice language-wide
>> uniformity:
>>
>> • Anywhere the syntax allows “let” it also allows “var,” and vice versa.
>> • Where they’re allowed, exactly one of them _must_ appear.
>>
>> The exception I can think of is for loops, where the iterator variable’s
>> “let” is still implied. (Are there others?) It would be more uniform, I
>> suppose, to require this:
>>
>> for let i in 0..<256
>>
>> …but that just looks intolerably awkward to my eyes.
>>
>> Cheers, P
>>
>>
>> On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> The core team met to discuss SE-0003, and we have a new conclusion,
>> described below.  As was mentioned on the other thread, this proposal is a
>> bit unusual because it predates Swift open source, and thus didn’t go
>> through the full evolution process, nor did it get the normal public review
>> that would come with it.
>>
>>
>> The core team broke this proposal down into a few different cases, each
>> of which came to a different conclusion.  To be clear up front, this is not
>> a clear-cut topic, and there are opinions on all sides.  Here are the
>> decisions the core team came to, along with some rationale:
>>
>>
>> *Parameter Lists*
>>
>> ‘var’ in a parameter list is problematic for a number of reasons:
>>
>> - Parameter lists currently allow both “inout” and “var”, and real
>> confusion occurs for some people learning swift that expect “var” to
>> provide reference semantics.
>>
>> - Parameter lists are not “patterns” in the language, so neither “let”
>> nor “var” really make sense there.  Parameters were patterns in a much
>> older swift design, but that was eliminated a long time ago and this aspect
>> never got reconsidered.
>>
>> - “var” in a parameter list is odd because it is an implementation detail
>> being foisted on the interface to the function.  To be fair, we already
>> have this with "API names" vs "internal names”, but this is a bigger
>> semantic implementation detail.
>>
>>
>> Conclusion: The core team decided that we should REMOVE “var” and “let”
>> from parameter lists.
>>
>> “var” in a parameter list is convenient sugar that defines away some
>> minor boilerplate (the shadowing copy), however, the cost benefit tradeoff
>> doesn’t pay enough to keep it.
>>
>>
>> *Patterns*
>>
>> "if var”, “for var”, "if case var" etc all use the pattern grammar (aka
>> "pattern matching" and “destructuring” features described in TSPL).  We
>> discussed whether to eliminate var from this, with much more mixed results:
>>
>> - We currently have a duality across the language between var and let
>> which is common, unifying, and works really well in practice.  Eliminating
>> var from pattern matching would make the language less uniform, because
>> patterns wouldn’t align with var/let declarations.
>>
>> - Working in Swift *demands* that you get an early grasp on what value
>> semantics means, and “var x = y” is always a copy of the value.  As such,
>> based on the strong duality mentioned above, it is reasonable to expect
>> people to learn that “if var x = y” produces a copy and not a reference
>> binding.
>>
>> - There certainly is confusion from people who expect “if var” to do a
>> reference binding, despite the comment directly above.  However, we feel
>> that this is more of a point-in-time confusion than the parameter case,
>> given that the parameter case exposes the ‘var’ as part of the function
>> signature.
>>
>>
>> Conclusion: The core team decided that we should KEEP “var” and “let” in
>> patterns.
>>
>>
>> *Case Patterns*
>>
>> We had an additional discussion focused specifically on whether it would
>> make sense to ban var in case patterns, e.g.:
>> case .Foo(var x):
>>
>> - The core team agrees that this specific case is a common point of
>> confusion, particularly because Swift doesn’t provide a way to get a
>> mutable binding to the associated value in an enum.
>>
>> - That said, making a special case for this would make Swift less regular.
>>
>>
>> Conclusions:
>> - The core team decided to KEEP “var” here.
>> - We will stop leading people into it by eliminating the "note: change
>> 'let' to 'var' to make it mutable” note that the compiler produces for
>> patterns.
>>
>> Eliminating the note allows users sufficiently knowledgable about Swift
>> to keep using it, but people who just mash the “fixit” button to silence
>> the compiler won’t get surprising behavior.
>>
>> -Swift Core Team
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>> _______________________________________________
>> 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/20160129/f682ced2/attachment.html>