[swift-evolution] [Proposal] Adjusting `inout` Declarations for Type Decoration
Trent Nadeau
tanadeau at gmail.com
Fri Jan 29 13:47:05 CST 2016
+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> wrote:
> +1
>
> On Jan 29, 2016, at 11:37, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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-annotationtype-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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/39cb03a3/attachment.html>
More information about the swift-evolution
mailing list