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

[Trent Nadeau]

   1. This is an opinion where people may disagree. However, the confusion
   with C semantics and how they do actually interact with Swift is important
   here, as Dmitri, Jordan, and Joe mentioned above.
   2. See above. Given the semantics confusion, I and others think we
   should have something different. If we need a different way to express
   that, having symmetry between the declaration and use seems like it could
   be a good pick.
   3. It's true there is already asymmetry in this area. However, I don't
   think we should have such if we can avoid it. Mutating functions, at least,
   have compiler errors to find out where you're misusing them such as calling
   one on a constant value type. Parameter labels vs. argument names require,
   I think, an unavoidable divergence in grammar due to have 1-2 names in one
   place and 0-1 names in the other.
   4. Allowing Rust-like borrowing is not the main reason for this
   proposal, the symmetry and avoidance of confusing semantics are. However,
   freeing up the & symbol would more easily allow for a feature that I and
   others (including Chris Lattner) think would be very useful, especially in
   constrained environments. One of the promises of future Swift is to stretch
   from systems programming to scripting.


On Fri, Jan 29, 2016 at 7:35 PM, Allen Ding <allen at snappymob.com> wrote:

> My 2 cents.
>
> 1. At the use site (and in actual usage in my code), func(&value) is a
> visually recognizable enough pattern that it is "obvious" when I read it.
>
> 2. At the call use, func(inout value) would also be obvious, but feels
> clunkier and may even be less immediately recognizable. Just my opinion. I
> find symbols easier to pick out when reading.
>
> 3. I really need to be convinced that symmetry of usage at call site (for
> any language feature) and declaration is a desirable thing. In my opinion,
> declaration and use are orthogonal things and a lot of Swift already
> exhibits this asymmetry. e.g. parameter labels vs argument names, why
> doesn't calling a mutating func require mutating somewhere in the call to
> make it obvious the call might mutate the receiver.
>
> 4. The possibility of Swift becoming more Rust-like and letting this
> possibility drive this discussion does not seem like it should factor into
> the discussion of whether this proposal is a win.
>
>
> On Sat, Jan 30, 2016 at 6:44 AM, Trent Nadeau via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> 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)
>> * 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>


-- 
Trent Nadeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/80351092/attachment.html>