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

[Erica Sadun]

I like this because it removes another C-like artifact that can be misunderstood ("& creates a pointer to this object") but I defer to Joe to make the call.

-- E

> On Jan 29, 2016, at 12:47 PM, Trent Nadeau <tanadeau at gmail.com> wrote:
> 
> +1
> 
> I would also like to change the call site to use inout as well.
> 
> foo(inout myVariable)
> 
> On Fri, Jan 29, 2016 at 2:40 PM, Dave via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> +1
>> On Jan 29, 2016, at 11:37, 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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
> 
> -- 
> Trent Nadeau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160129/2df23383/attachment.html>