[swift-evolution] [Proposal] Use inout at function call sites
Erica Sadun
erica at ericasadun.com
Fri Jan 29 17:48:00 CST 2016
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> 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
>
> _______________________________________________
> swift-evolution mailing list
> 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/7b2fb660/attachment.html>
More information about the swift-evolution
mailing list