<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">For the record, this is not correct. 'inout' already appears in function types:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">let foo: (inout Int) -> Void</div><div class="">foo = { $0 += 1 }</div><div class=""><br class=""></div><div class="">var x = 0</div><div class="">foo(&x)</div><div class="">print(x) // 1</div></blockquote><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 10:38, Антон Жилин via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><span style="font-size:12.8px" class="">Several people have already agreed that 'inout' should be placed before types in parameter lists:</span></div><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><span style="font-size:12.8px" class="">func foo(x: inout Int)</span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">I'm strongly against such a change an will explain why.<br class=""></span><div class=""><span style="font-size:12.8px" class=""><br class=""></span></div><div class=""><span style="font-size:12.8px" class="">'The Swift Programming Language' states that there are 2 distinct kinds of modifiers:</span></div><div class=""><span style="font-size:12.8px" class="">1. Declaration attributes</span></div><div class=""><span style="font-size:12.8px" class="">2. Type attributes</span></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">For example, I can declare a @convention(c) variable</div><div class="">let test: @convention(c) Int -> Void</div><div class="">But I cannot declare an @autoclosure variable:</div><div class="">let test: @autoclosure () -> Bool</div><div class="">And that's OK because @autoclosure makes no sense here. It is not a type attribute at all.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class="">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.</div></div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ZEz4qHYnXhPr3bBPu-2FxP4tN3HfWKL-2FtJpqkQ0gkOVSAh2hyzmewRTpH2cro4AthEJR6ochHWOQyloCmYLvorP-2FiEJEWHerIAGUG3PHudpuAQ80XQ7lkKyVbgMMGj2yjhOTDHg0JF53c55iE2ErqRr-2FTDF3oJr3q85Iw5P061PcdgC2dolyrmOrjtau-2FYreDbf5k6SCiiw3HcPC8FwN74JqYJNiTv3b85HVcl0qCDKxY-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>