<div dir="ltr">While we were discussing this proposal, a team member objected saying he had fixed a bug related to using `var` this summer. It turned out he had actually fixed the bug by switching to `inout` _from_ `var`. This is an experienced dev with plenty of resources and Swift knowledge.<div><br></div><div>So yes, it is not only possible but has definitely happened that this confusion exists for some developers. We were surprised but group conclusion was it validated the proposal. I was ambivalent on the proposal initially, but overall I think it is the right direction for Swift. </div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Step Christopher<div>Big Nerd Ranch, LLC<br></div><div><a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.com</a></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On Tue, Dec 15, 2015 at 5:27 PM, Francisco Costa via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hello all,<br><br></div>There is currently a proposal to remove `var` from Function Parameters and Pattern Matching which seems to have been already accepted<br><br><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters-patterns.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters-patterns.md</a><br><br></div>I cannot find the discussion on it, probably because it predates the open sourcing of Swift. While some of its arguments may sound reasonable, I think they have been greatly exaggerated.<br><br>The main point of the proposal seems to be that the `var` attribute can be easily confused with `inout`. It then provides examples where `var` would be completely useless:<br><br>```<br><span style="font-family:monospace,monospace">func foo(i: Int) {<br> i += 1 // Illegal<br>}<br><br>func foo(var i: Int) {<br> i += 1 // Legal but useless since we are not using this local value anywhere<br>}<br></span></div><div>```<br><br></div><div>We today made a quick survey around the backend developers on the office (not familiar with Swift) and not a single one suggested that the second method would mutate the original parameter value. In fact, to all of them it was clear that `var` creates a local copy of the value and that the method is also missing a `return` if we want to use the incremented value.<br><br></div><div>The Swift Language Guide gives a good explanation on this as well:<br><br>"Variable parameters ... give a new modifiable copy of the parameter’s value for your
function to work with."<br><br></div><div>This is probably a concept most beginners to the language can either guess intuitively or learn in a couple of seconds.<br></div><div><br></div><div>Especially taking into account that the way we use `inout` parameters is so much advertised in Swift, to the point where calling a method with them requires to explicitly identify them with `&`, it seems that by giving up the `var` attribute we would lose a convenient elegance in exchange for no real benefit to beginners.<br></div><div><br></div><div>In fact, in my experience the `var` attribute is most often used in scenarios where immutability is intentionally preserved, we pass a immutable value to a method and it returns another immutable (modified) version of that value.<br><br></div><div>Another common scenario is when you need to further modify a value that was unwrapped from an Optional. I would argue that this seems elegant and easy to read:<br><br>```<br><span style="font-family:monospace,monospace">if var x = getOptionalInt() {<br> x += 1<br> return x<br>}</span><br>```<br></div><div><br>While this (as has been proposed) seems like we are fighting a language limitation:<br></div><div><br>```<br><span style="font-family:monospace,monospace">if let x = getOptionalInt() {<br> var x = x<br> x += 1<br> return x<br>}</span><br>```<br><br></div><div>I understand that discussing back and forth proposals that have been already accepted is counter-productive, but since this discussion doesn't seem to have been published, I would kindly ask if we can give it a second thought :)<br><br></div><div>Thanks,<br></div><div>Francisco<br></div><div><br></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=FcqcGV1X8K7Vnxfj3w9H7RBvIFFHk0as3UHXRDc-2BSJvc9gHOMx29SQzcVysNlej4r1hG7htcqbqpLlg7YIEf3Av03Ip91mbXGTq8xfb6moPyB9Mhu0c1iv2ym0by9JIsvp4SddPlWD6H8ZOw-2F7K9eHBsxDukpUnXDvKOl7-2BjTKLpoN6m5kSt5JzcYOttCca1H6H4Qx2k8awYx1VEAqx2JuMspG3tVqWrSS9JuMQLgok-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>