Walter Bright Wrote:
> Andrei Alexandrescu wrote:
> > Time has come to make a decision on implementing Steven Schveighoffer's
> > proposal:
>
> Unmentioned in the proposal is is inout a type constructor or a storage
> class? For example,
>
> U[inout(T)]* foo(inout(X)*** p) { ... }
>
> This is much more complex to implement than only allowing inout at the
> top level, i.e. as a storage class.
>
> I also prefer the idea of inout on the return type being assumed, rather
> than explicit:
>
> T foo(inout U p) { ... }
>
> Yes, there's the legacy compatibility issue there. A long time ago, I
> suggested using the keyword 'return' for that, instead of inout:
>
> T foo(return U p) { ... }
>
> which looks fine until you use it for member functions:
>
> T foo() return { ... }
>
> ugh.
I initially liked return as the keyword as well, but it's problematic for
intermediate variables.
inout(U) foo(inout(T) t){
inout V v = t.someMember.somethingElse;
return bar(v);
}
