<div dir="ltr"><div><div>Thanks Stephen for the insight!<br><br></div>The way Swift prevents
us from inadvertently writing common bugs is one of the many things
that makes it great, and I absolutely agree that this confusion must be
handled. However I would still prefer if this would be less aggressively
fixed with a warning telling us when a struct has been copied but the
new value has not been returned or used in the outer scope, rather than
removing the feature entirely. How hard it would be to implement such a
warning I am not sure though.<br><br></div>Francisco<br><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 12:29 AM, Stephen Christopher <span dir="ltr"><<a href="mailto:schristopher@bignerdranch.com" target="_blank">schristopher@bignerdranch.com</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">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><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"><div><div class="h5">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></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=FcqcGV1X8K7Vnxfj3w9H7RBvIFFHk0as3UHXRDc-2BSJvc9gHOMx29SQzcVysNlej4r1hG7htcqbqpLlg7YIEf3Av03Ip91mbXGTq8xfb6moPyB9Mhu0c1iv2ym0by9JIsvp4SddPlWD6H8ZOw-2F7K9eHBsxDukpUnXDvKOl7-2BjTKLpoN6m5kSt5JzcYOttCca1H6H4Qx2k8awYx1VEAqx2JuMspG3tVqWrSS9JuMQLgok-3D" alt="" 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" height="1" border="0" width="1">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
</blockquote></div><br></div>