[swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration

[Taras Zakharko]

I really like this proposal, so its a +1 from me. It really clarifies that inout is implemented via an implicit reference type that wraps the original value. To make thinks more consistent, one could also think about adding generic reference types to the language (inout T then becomes syntactic sugar for Reference<T>), however, I am not sure that such an addition would be that valuable. But this proposal would certainly open up a path for introducing references, if deemed reasonable at some point. 

— Taras


> On 30 Jan 2016, at 21:28, Patrick Gili via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +1
> 
> This is very reasonable and clarifies usage.
> 
>> On Jan 29, 2016, at 2:37 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> https://github.com/apple/swift-evolution/pull/127 <https://github.com/apple/swift-evolution/pull/127>
>> 
>> Adjusting inout Declarations for Type Decoration
>> 
>> Proposal: TBD
>> Author(s): Joe Groff <https://github.com/jckarter>, Erica Sadun <http://github.com/erica>
>> Status: TBD
>> Review manager: TBD
>> Introduction
>> 
>> The inout keyword indicates copy-in/copy-out argument behavior. In its current implementation
>> the keyword prepands argument names. We propose to move the inout keyword to the right
>> side of the colon to decorate the type instead of the parameter label. 
>> 
>> The initial Swift-Evolution discussion of this topic took place in the “Replace ‘inout’ with &” thread.
>> 
>> Motivation
>> 
>> In Swift 2, the inout parameter lives on the label side rather than the type side of the colon
>> although the keyword isn’t modifying the label but its type. Decorating
>> types instead of labels offers identifiable advantages: 
>> 
>> It enables the inout keyword to properly integrate into full type syntax, for example: 
>> (x: inout T) -> U // => (inout T) -> U
>> It avoids notational similarity with arguments labeled inout, for example:
>> func foo(inOut x: T) // foo(inOut:), type (T) -> Void
>> func foo(inout x: T) // foo(_:), type (inout T) -> Void
>> It better matches similar patterns in other languages such as borrowing in Rust, that may be later introduced back to Swift 
>> Detailed design
>> 
>> parameter → external-parameter-name optlocal-parameter-name : type-annotation
>> type-annotation → inout type-annotation
>> Alternatives Considered
>> 
>> Decorations using @inout (either @inout(T) or @inout T) were considered and discarded
>> 
>> _______________________________________________
>> 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/20160130/4ffa3fe6/attachment.html>