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

[Jordan Rose]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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