[swift-evolution] [Pitch] Replace 'inout' with '&': Clarification

Антон Жилин antonyzhilin at gmail.com
Fri Jan 8 12:38:24 CST 2016

Several people have already agreed that 'inout' should be placed before
types in parameter lists:

func foo(x: inout Int)

I'm strongly against such a change an will explain why.

'The Swift Programming Language' states that there are 2 distinct kinds of
1. Declaration attributes
2. Type attributes

Declaration attributes, specifically @autoclosure and @noescape, have no
meaning outside function parameter lists. They are therefore placed before
the variables themselves to visually differentiate them from actual type

Type attributes, specifically @convention and @noreturn, are applied to
types. They are true type modifiers, and form a new type that can be used
everywhere a normal type can.

For example, I can declare a @convention(c) variable
let test: @convention(c) Int -> Void
But I cannot declare an @autoclosure variable:
let test: @autoclosure () -> Bool
And that's OK because @autoclosure makes no sense here. It is not a type
attribute at all.

Now look at 'inout'. Currently, 'inout' is (semantically) a declaration
attribute. We cannot return inout from function, we cannot declare an inout
variable. 'inout' only makes sense in parameter lists. We should then treat
it like @autoclosure and not like @convention(c). It should then be placed
like them, i.e. before the parameter itself, like it is placed now.

TLDR: 'inout' is placed before parameters for consistency with (other)
declaration attributes. (Parameter) declaration attributes are placed
before parameters to hint that they make sense only in parameter lists.

Another question is if we change 'inout' to act like a type attribute,
essentially adding C++-style references to Swift. Only then would it be
logical to place 'inout' before types.
It seems like there is no corresponding thread yet. I'm personally against
it. If some people think otherwise, we could start a new thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/08b68bf3/attachment.html>

More information about the swift-evolution mailing list