<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><br class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The core team met to discuss SE-0003, and we have a new conclusion, described below. &nbsp;As was mentioned on the swift-evolution discussion 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.<div class=""><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="">The core team broke this proposal down into a few different cases, each of which came to a different conclusion. &nbsp;To be clear up front, this is not a clear-cut topic, and there are opinions on all sides. &nbsp;Here are the decisions the core team came to, along with some rationale:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Parameter Lists</b></div><div class=""><br class=""></div><div class="">‘var’ in a parameter list is problematic for a number of reasons:</div><div class=""><br class=""></div><div class="">- Parameter lists currently allow both “inout” and “var”, and real confusion occurs for some people learning swift that expect “var” to provide reference semantics.</div><div class=""><br class=""></div><div class="">- Parameter lists are not “patterns” in the language, so neither “let” nor “var” really make sense there. &nbsp;Parameters were patterns in a much older swift design, but that was eliminated a long time ago and this aspect never got reconsidered.</div><div class=""><br class=""></div><div class="">- “var” in a parameter list is odd because it is an implementation detail being foisted on the interface to the function. &nbsp;To be fair, we already have this with "API names" vs "internal names”, but this is a bigger semantic implementation detail.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Conclusion: The core team decided that we should REMOVE “var” and “let” from parameter lists.</div><div class=""><br class=""></div><div class=""><div class="">“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.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Patterns</b></div><div class=""><br class=""></div><div class="">"if var”, “for var”, "if case var" etc all use the pattern grammar (aka "pattern matching" and “destructuring” features described in TSPL). &nbsp;We discussed whether to eliminate var from this, with much more mixed results:</div><div class=""><br class=""></div><div class="">- We currently have a duality across the language between var and let which is common, unifying, and works really well in practice. &nbsp;Eliminating var from pattern matching would make the language less uniform, because patterns wouldn’t align with var/let declarations.</div><div class=""><br class=""></div><div class="">- 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. &nbsp;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.</div><div class=""><br class=""></div><div class="">- There certainly is confusion from people who expect “if var” to do a reference binding, despite the comment directly above. &nbsp;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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><div class="">Conclusion: The core team decided that we should KEEP “var” and “let” in patterns.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Case Patterns</b></div><div class=""><br class=""></div><div class="">We had an additional discussion focused specifically on whether it would make sense to ban var in case patterns, e.g.:</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>case .Foo(var x):</div><div class=""><br class=""></div><div class="">- 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.</div><div class=""><br class=""></div><div class="">- That said, making a special case for this would make Swift less regular.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Conclusions:&nbsp;</div><div class="">- The core team decided to KEEP “var” here.</div><div class="">- 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-Swift Core Team</div><div class=""><br class=""></div></div></div></div></body></html>