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

[Charles Kissinger]

The one downside I see to this is that it puts the ‘inout’ in a less prominent position. It looks fine after an argument name like ‘x’, but if the argument is named ‘textRepresentation’ or something longer like that, the ‘inout’ isn’t quite as noticeable as it is now, particularly if it’s in a long parameter list. In cases where the the inout parameter is the first one in the function call, the current position for ‘inout’ allows it to stand out nicely at the head of the line.

So a +/-1 for me.

The related idea of replacing ‘&’ with ‘inout’ at the call site seems completely contradictory to this proposal. Developers would then have to remember that the ‘inout’ goes before the argument at the call site but after it in the function definition. That seems like a constant source of mis-typings and something that would be viewed as an inconsistency in the language. Or do people want to put it after the argument name at the call site too? It seems a little like change just for the sake of change, IMO.

—CK

> On Jan 29, 2016, at 11:37 AM, 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/1d0f76d3/attachment.html>