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

[Matthew Johnson]

+1.  The original thread also discussed using `inout` rather than `&` at the call site.  Are you thinking of following this up with a proposal to change that so usage matches declaration better?

> On Jan 29, 2016, at 1:37 PM, Erica Sadun via swift-evolution <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
> 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/0b0c0b8b/attachment.html>