<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="">A very reasonable decision! It is also good to know that accepted proposals are not “absolute” but will be reviewed again if necessary. <div class=""><br class=""></div><div class=""><div class="">— Taras</div><div class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Jan 2016, at 07:20, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><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=""><div class="">+3 from me — one for each of the conclusions. This sounds exactly right.</div><div class=""><br class=""></div><div class="">If I understand correctly, we now alllmost have a nice language-wide uniformity:</div><div class=""><br class=""></div><div class="">• Anywhere the syntax allows “let” it also allows “var,” and vice versa.</div><div class="">• Where they’re allowed, exactly one of them _must_ appear.</div><div class=""><br class=""></div><div class="">The exception I can think of is for loops, where the iterator variable’s “let” is still implied. (Are there others?) It would be more uniform, I suppose, to require this:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>for let i in 0..<256</div><div class=""><br class=""></div><div class="">…but that just looks intolerably awkward to my eyes.</div><div class=""><br class=""></div><div class="">Cheers, P</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 28, 2016, at 11:41 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><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. 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.<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. 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:</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. 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. 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). 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. 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. 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. 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: </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 class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>