[Proposal] Adjusting `inout` Declarations for Type Decoration

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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

+1

···

On Jan 29, 2016, at 11:37, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This makes sense to me, but why shouldn't it also apply to things like
@noescape? I can understand that @autoclosure is really more an annotation
of the function signature than it is of the type, but it seems like the
same arguments for inout could be used for @noescape.

Jacob

···

On Fri, Jan 29, 2016 at 11:37 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

   - Proposal: TBD
   - Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun
   <http://github.com/erica&gt;
   - 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+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@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+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@swift.org> wrote:

+1

On Jan 29, 2016, at 11:37, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

   - Proposal: TBD
   - Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun
   <http://github.com/erica&gt;
   - 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

[ Proposal link: Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub ]

+1. As has been noted elsewhere, inout isn't just part of the parameter (since it appears in function types), and it's not part of the parameter's type (since within the body there's no inout-ness, and you can't put 'inout' in a typealias on its own). To me, that means neither side of the colon is inherently "correct", and therefore I prefer the slight consistency with function types and with call sites, and the removal of the possibility for typos becoming external parameter names.

Jordan

Surely inout isn’t a modifier of the type either, but rather a modifier of the parameter as a whole, not the label specifically. Couldn’t we just allow the label to be omitted for closures such as in your (inout T) -> U example?

I don’t suppose it really matters if we’re considering getting rid of var on parameters (so they’re all immutable by default if not inout), so it could go anywhere, I just think that it’s a bit strange to associate with the type specifically when it’s not really specific to that either IMO.

···

On 29 Jan 2016, at 19:40, Dave via swift-evolution <swift-evolution@swift.org> wrote:

+1

On Jan 29, 2016, at 11:37, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1

This is very reasonable and clarifies usage.

···

On Jan 29, 2016, at 2:37 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

+1
It's better than the current form — but imho there is alternative that is worth being discussed:

(inout T) is a type on its own, right? (I guess although everyone seems to avoid the word, it is actually implemented as a pointer ;-)

Building on this, type "inout T" is associated with T, and it could be expressed using established syntax:
T.Inout (or T.Reference…)

I'm not sure which choice I like better, but as long as there are no other type modifiers, I have a preference for replacing special syntax with something that is there anyway.

Tino

Seems reasonable to me, worth its own discussion thread.

-Joe

···

On Jan 29, 2016, at 1:45 PM, Erica Sadun <erica@ericasadun.com> wrote:

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.

Independent of whether this is a good idea or not, I’d strongly suggest making it be a different proposal.

-Chris

···

On Jan 29, 2016, at 1:45 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

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.

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@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
+1

On Jan 29, 2016, at 11:37, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Trent Nadeau

If you have a function

f(x: Int) {}

you call it with f(8), and potentially f(x: 8). Even when labeled, the 8 value is to the right of the colon.

Now consider

f(x: inout Int) {}

you call it with f(&y) or f(inout y), and with a label, you'd call it f(x: &y) or f(x: inout y).

It seems consistent to me.

···

On Jan 29, 2016, at 3:04 PM, Charles Kissinger <crk@akkyra.com> wrote:
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.

Makes sense. I can write that up and start a new thread.

···

On Fri, Jan 29, 2016 at 4:47 PM, Chris Lattner <clattner@apple.com> wrote:

> On Jan 29, 2016, at 1:45 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>
> 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.

Independent of whether this is a good idea or not, I’d strongly suggest
making it be a different proposal.

-Chris

--
Trent Nadeau

It works for me because I think of the mutability of a variable being part of the type of the variable

I do like the proposal although I haven't had cause to make use of inout arguments much recently.

Joseph

···

On 29 Jan 2016, at 20:55, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Surely inout isn’t a modifier of the type either, but rather a modifier of the parameter as a whole, not the label specifically. Couldn’t we just allow the label to be omitted for closures such as in your (inout T) -> U example?

+1 for me including changing the call site to match, IE:

    func add(number n: inout Int)
    add(number: inout n)

···

On Saturday, 30 January 2016, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

[ Proposal link: Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub ]

+1. As has been noted elsewhere, inout isn't *just* part of the parameter
(since it appears in function types), and it's not part of the parameter's
type (since within the body there's no inout-ness, and you can't put
'inout' in a typealias on its own). To me, that means neither side of the
colon is inherently "correct", and therefore I prefer the slight
consistency with function types and with call sites, and the removal of the
possibility for typos becoming external parameter names.

Jordan

--
  -- Howard.

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@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@swift.org <mailto:swift-evolution@swift.org>> wrote:

Adjusting declarations for type decoration proposal by erica · Pull Request #127 · apple/swift-evolution · GitHub

Adjusting inout Declarations for Type Decoration

Proposal: TBD
Author(s): Joe Groff <https://github.com/jckarter&gt;, Erica Sadun <http://github.com/erica&gt;
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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

(inout T) is not a type on its own*, and it is not equivalent to a pointer. If it were, you could have local variables of type "inout T", and you wouldn't be able to use computed properties with inout.

* The compiler represents "inout T" as a distinct type, but it also represents "lvalue T" and "weak T" and "generic T without any bound generic arguments" as types, so it's not really relevant here.

Jordan

···

On Feb 3, 2016, at 4:16, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

+1
It's better than the current form — but imho there is alternative that is worth being discussed:

(inout T) is a type on its own, right? (I guess although everyone seems to avoid the word, it is actually implemented as a pointer ;-)

Sorry, I wasn’t clear at all there. I was thinking of the most common case where there is either only one parameter or the inout parameter is the first one. Then there will typically be no argument label involved at the call site. In that case ‘inout’ will be the first word inside the parens at the call site (assuming it replaces ‘&’). If it also is kept in its current position in function declarations, it will be in that same leading position in declarations and (I’m assuming) people will have an easy time remembering where to put it.

When there is a label involved, it is a different story. I was implicitly, and probably wrongly, assuming that would be a much less common case in practice. A poorly worded, and probably poorly reasoned, argument on my part, though I still don’t see any great advantage to replacing ‘&'.

—CK

···

On Jan 29, 2016, at 2:13 PM, Erica Sadun <erica@ericasadun.com> wrote:

On Jan 29, 2016, at 3:04 PM, Charles Kissinger <crk@akkyra.com <mailto:crk@akkyra.com>> wrote:
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.

If you have a function

f(x: Int) {}

you call it with f(8), and potentially f(x: 8). Even when labeled, the 8 value is to the right of the colon.

Now consider

f(x: inout Int) {}

you call it with f(&y) or f(inout y), and with a label, you'd call it f(x: &y) or f(x: inout y).

It seems consistent to me.