[swift-evolution] Proposal: Keep var on Function Parameters and Pattern Matching

[Fabian Ehrentraud]

While I think it's good to loose `var` for parameters, the different semantics for Structs and Classes can be confusing sometimes. It is not always obvious at caller site, whether you are passing a Struct or a Class instance, and therefore whether the call will alter the instance at caller site.


On 16.12.2015, at 03:33, Dennis Lysenko via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:

Francisco,

Can you run the same survey with an example that uses a struct called "Song" instead? I think the confusion would lie in complex value types. Int may be an unideal example.

On Tue, Dec 15, 2015, 5:27 PM Francisco Costa via swift-evolution <swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:
Hello all,

There is currently a proposal to remove `var` from Function Parameters and Pattern Matching which seems to have been already accepted

https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters-patterns.md

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.

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:

```
func foo(i: Int) {
  i += 1 // Illegal
}

func foo(var i: Int) {
  i += 1 // Legal but useless since we are not using this local value anywhere
}
```

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.

The Swift Language Guide gives a good explanation on this as well:

"Variable parameters ... give a new modifiable copy of the parameter’s value for your function to work with."

This is probably a concept most beginners to the language can either guess intuitively or learn in a couple of seconds.

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.

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.

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:

```
if var x = getOptionalInt() {
  x += 1
  return x
}
```

While this (as has been proposed) seems like we are fighting a language limitation:

```
if let x = getOptionalInt() {
  var x = x
  x += 1
  return x
}
```

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 :)

Thanks,
Francisco

 _______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto:swift-evolution at swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
 _______________________________________________
swift-evolution mailing list
swift-evolution at swift.org<mailto: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/20151216/d93b69c7/attachment.html>