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
modifiers:
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
attributes.
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.
For the record, this is not correct. 'inout' already appears in function types:
let foo: (inout Int) -> Void
foo = { $0 += 1 }
var x = 0
foo(&x)
print(x) // 1
Jordan
···
On Jan 8, 2016, at 10:38, Антон Жилин via swift-evolution <swift-evolution@swift.org> wrote:
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 modifiers:
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 attributes.
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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution