[swift-evolution] [Proposal] Use inout at function call sites

[Jordan Rose]

The reasoning here was that the operator itself would be enough signal to tell you that it's mutating one of its arguments. "&count += 1" would be a little too much.

Similarly, mutating methods take 'self' inout, but as noted before you aren't required to write 'mutating' at the call site, because it's assumed the name will be signal enough. This doesn't scale to arbitrary numbers of arguments, though, especially when you normally don't even think about some of your arguments being changed by a function call.

Mutating functions and assignment operators are fairly common (at least when not eschewing imperative programming). General inout parameters are not.

Jordan

P.S. At one point we thought about requiring you to declare "assignment" in your operator declaration, and disallowing inout parameters from arbitrary other operators, but that didn't actually turn into a proposal. It's not a bad idea, though—just a bit of compiler-enforced consistency.

> On Jan 29, 2016, at 15:48 , Erica Sadun <erica at ericasadun.com> wrote:
> 
> I started poking around. It looks like the rules for calls with functions are different from those with operators. At least in the following example, the operator version doesn't need the &. Any idea why?
> 
> -- Erica
> 
> 
> //--------------------------------------------------------------
> // Stream Printing
> //--------------------------------------------------------------
> import Darwin
> import Foundation
> 
> public struct StdErrStream: OutputStreamType {
>     public mutating func write(string: String) {
>         puts(string.cStringUsingEncoding(NSUTF8StringEncoding)!)
>     }
> }
> 
> var stdStream = StdErrStream()
> print("hello world", toStream: &stdStream)
> 
> vs
> 
> //--------------------------------------------------------------
> // MARK: Conditional Assignment
> //--------------------------------------------------------------
> 
> infix operator =? {}
> 
> /// Conditionally assign optional value to target via unwrapping
> /// Thanks, Mike Ash
> func =?<T>(inout target: T, newValue: T?) {
>     if let unwrapped = newValue { target = unwrapped }
> }
> 
> import UIKit
> var image = UIImage()
> var replacement = [#Image(imageLiteral: "Screen Shot 2016-01-29 at 4.35.48 PM.png")#]
> image =? UIImage(named: "DoesNotExist")
> 
> 
> -- E
> 
> 
>> On Jan 29, 2016, at 4:23 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> +1 from me, but I suggest finding some real-world examples of inout (and UnsafePointer) and showing those, rather than a made-up add1. The fact that we currently require '&' for Unsafe-(immutable)-Pointer might make this a bit less nice than it otherwise would be.
>> 
>> (We've talked about allowing pass-by-value for UnsafePointer, but that has its own pros and cons, and should be discussed separately.)
>> 
>> Jordan
>> 
>> 
>>> On Jan 29, 2016, at 14:44, Trent Nadeau via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md <https://github.com/tanadeau/swift-evolution/blob/master/proposals/00xx-use-inout-at-func-call-site.md>
>>> 
>>> # Use `inout` at Function Call Sites
>>> 
>>> * Proposal: TBD
>>> * Author(s): [Trent Nadeau](http://github.com/tanadeau <http://github.com/tanadeau>)
>>> * Status: TBD
>>> * Review manager: TBD
>>> 
>>> ## Introduction
>>> 
>>> Currently when a function has `inout` parameters, the arguments are passed with the `&` prefix operator. For example:
>>> 
>>> ```swift
>>> func add1(inout num: Int) {
>>>     num += 1
>>> }
>>> 
>>> var n = 5
>>> add1(&n) // n is now 6
>>> ```
>>> 
>>> This operator does not fit with the rest of the language nor how the parameter is written at the function declaration. It should be replaced so that `inout` is used in both locations so that the call site above would instead be written as:
>>> 
>>> ```swift
>>> add1(inout n) // symmetric and now obvious that n can change
>>> ```
>>> 
>>> *Discussion thread TBD*
>>> 
>>> ## Motivation
>>> 
>>> The `&` prefix operator is a holdover from C where it is usually read as "address of" and creates a pointer. While very useful in C due to its pervasive use of pointers, its meaning is not the same and introduces an unnecessary syntactic stumbling block from users coming from C. Removing this operator and using `inout` removes this stumbling block due to the semantic change.
>>> 
>>> This operator is also disconnected from how the function declaration is written and does not imply that the argument may (and likely will) change. Using `inout` stands out, making it clear on first read that the variable may change.
>>> 
>>> It is also possible that Swift may add Rust-like borrowing in the future. In that case, the `&` symbol would be better used for a borrowed reference. Note that Rust uses the same symbol for declaring a borrowed reference and creating one, creating a nice symmetry in that respect of the language. I think Swift would want to have such symmetry as well.
>>> 
>>> ## Detailed design
>>> 
>>> ```
>>> in-out-expression → inout identifier
>>> ```
>>> 
>>> ## Alternatives Considered
>>> 
>>> Keeping the syntax as it currently is.
>>> 
>>> -- 
>>> Trent Nadeau
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160129/aa2e716a/attachment.html>