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

[Kevin Ballard]

I agree 100% with everything Jordan said.

-Kevin Ballard

On Sat, Dec 19, 2015, at 07:06 PM, Jordan Rose via swift-evolution wrote:
> -1 to using '&' in the declaration; it's a sigil that doesn't mean
> anything as is. (I was originally on the side of using 'inout' at the
> call site as well, i.e. "swap(inout x, inout y)", but it was
> considered too verbose.)
>
> I don't like it as an attribute because attributes generally don't
> affect the *syntax* of how something is used; they're mostly just
> implementation detail. Obviously they can have important semantics
> (like "@objc(…)" controlling the selector, or '@convention(c)' for C-
> compatible function pointers), but for the most part they don't change
> what the declaration is, whereas 'inout' *definitely* does.
>
> Given that we already use this syntax for function types when the
> parameter is unnamed, '(inout Int, inout named: Int) -> Void', I think
> Erica's first suggestion is my favorite so far.
>
> Jordan
>
>
>> On Dec 19, 2015, at 16:10 , Erica Sadun via swift-evolution <swift-
>> evolution at swift.org> 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) func foo(x: @inout(Int)) func foo(x:
>> @inout Int)
>>
>> Is there an underlying reason that parameter modification should live
>> on the name side rather than the type side of the colon? They aren't
>> really modifying the name
>>
>> -- Erica, inexperienced with Rust
>>
>>
>>> On Dec 18, 2015, at 7:07 PM, Chris Lattner via swift-evolution <swift-
>>> evolution at swift.org> wrote:
>>>
>>>
>>>> On Dec 18, 2015, at 5:23 PM, Joe Groff via swift-evolution <swift-
>>>> evolution at swift.org> wrote:
>>>>
>>>> For Swift 3, we're planning to phase out 'var' parameters in
>>>> functions, and we're also making it so that language keywords are
>>>> valid argument labels. With both of these changes pending, I have a
>>>> hard time not reading:
>>>>
>>>>> func foo(inout x: Int)
>>>>>
>>>> as an argument labeled `inout` instead of an unlabeled argument
>>>> bound to `x`. Once `var` is phased out, `inout` would also be the
>>>> only remaining case where quoting is necessary to use a name as an
>>>> argument label. The `inout` keyword has always struck me as weird,
>>>> since it violates definition-follows-use—maybe we should replace it
>>>> with the `&` sigil, mirroring its usage in call sites.
>>>
>>> -1
>>>
>>> “inout” is intended to communicate (or at least hint at) the copy-in
>>> / copy-out behavior of the argument.  It is also there to enable
>>> other parameter modifiers, which can enable other more advanced
>>> parameters models in the future (e.g. rust-style borrowing).
>>>
>>> -Chris
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> _________________________________________________
> 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/20151221/63b34c97/attachment.html>