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

[Kevin Ballard]

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.

-Kevin Ballard

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/8e0fdc50/attachment.html>