[swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching
vmartinelli at alecrim.com
Fri Jan 29 10:10:05 CST 2016
+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.
> "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
> - 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
> Conclusion: The core team decided that we should KEEP “var” and “let” in
> *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.
> - 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
> 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...
More information about the swift-evolution