[swift-evolution] [Pitch] Replace 'inout' with '&'

[Howard Lovatt]

+1 for having to mark calls to `inout` parameters with `inout` rather than
`&`, `&` is well entrenched in its C usage.

For repurposing of `&`; if you had library functions:

    class Reference<T> {
        let value: T
        init(value: T) { self.value = value }
    }

    class MutableReference<T> {
        var value: T
        init(value: T) { self.value = value }
    }

Then when you obtained something from a C library you wrapped it:

    let rect = MutableReference(CGRectMake(0,0,0,0))

Wouldn't that cover most use cases and be simpler than implementing a new
`&`?

The above classes would also have general purpose usage reference
semantics rather than `inout` semantics, e.g.:

    let array = [MutableArray(1), MutableArray(2)]

`array` can be passed to threads, used in closures, etc. without the copy
in and copy out semantics being surprising and unpredictable.

On Thursday, 7 January 2016, Trent Nadeau via swift-evolution <
swift-evolution at swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:

> +1
>
> Chris Lattner mentioned that he wants to have a version of Rust's
> borrowing syntax eventually. With this change, if we get that, then we keep
> a very symmetric syntax:
> func foo(x: inout T) called as foo(inout myT)
> func foo(x: &T) called as foo(&myT)
> func foo(x: &mut T) called as foo(&mut myT)
>
> On Wed, Jan 6, 2016 at 10:42 AM, Tahoma Toelkes via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> +1
>>
>> My sentiments exactly.  As I was catching up on this thread, this was
>> almost exactly the syntax I was already considering mentioning when I
>> encountered Erica's reply.
>>
>> I don't know whether it will meet all requirements; however, from a
>> readability perspective in both declarations and function type signatures,
>> this syntax is the first of the suggestions that feels clear to me.
>>
>> -- Tahoma
>>
>> On Dec 21, 2015, at 11:20 AM, Ricardo Parada via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Dec 19, 2015, at 4:10 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>
>> What would the ramifications of the following be? Each addresses the
>> "confusable with labeling" issue but preserve the inout keyword.
>>
>> func foo(x: inout Int)
>>
>> ...
>>
>>
>> I think I like this one better than all the others.
>> I have not analyzed all the implications of having it there but it feels
>> right.
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> 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
>>
>>
>
>
> --
> Trent Nadeau
>


-- 
  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/4608bbae/attachment.html>