> On Dec 18, 2015, at 6:08 PM, Dmitri Gribenko <griboz...@gmail.com> wrote:
>
> On Fri, Dec 18, 2015 at 5:23 PM, Joe Groff via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> For Swift 3, we're planning to phase out 'var' parameters in functions, and
> we're also making it so that language keywords are valid argument labels.
> With both of these changes pending, I have a hard time not reading:
>
> func foo(inout x: Int)
>
>
> I don't think this would be a problem in practice since it is hard for me to
> imagine an API that would use 'inout' as a label -- at least they would spell
> it 'inOut' according to our API guidelines (but I really think they should
> call it something else).
My main concern is readability of the declaration. 'func foo(inout x: Int)' and
'func foo(label x: Int)' look very similar at a glance, but have totally
different meanings. Going back to '@inout' like Slava suggested would be
another possible improvement.
> There's also a possibility that we add 'out' parameters in the future, and if
> 'inout' would be spelled '&', then we would need to find another sigil for
> 'out'.
We have multiple returns. Why would we ever add out parameters?
-Joe
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
