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

[Vanderlei Martinelli]

+1 :-) Thank the team for the decision and guidance.

On Friday, January 29, 2016, 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/b0df1f10/attachment.html>