[swift-evolution] SE-0003 Removing var from Function Parameters and Pattern Matching
kevin at sb.org
Fri Jan 29 13:44:34 CST 2016
This is great news! Thank you for being willing to reconsider this
proposal. And the explanation given in this email is really great. Even
though I stated earlier that ditching `var` in parameter lists is mildly
annoying, the rationale given here is very compelling. And the reasons
for keeping "var" everywhere else are spot-on too.
On Thu, Jan 28, 2016, at 09:41 PM, Chris Lattner via swift-evolution 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
> *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 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
> - 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution