Bug 1060 – inout in arguments breaks the lvalueness of function

int[] foo(int[] arr){ return arr; } int[] boo(inout int[] arr){ return arr; } int[] arr = [1,2,3]; foo(foo(arr)); // ok boo(boo(arr)); // Error: boo(arr) is not an lvalue

(In reply to comment #0) > int[] foo(int[] arr){ > return arr; > } > > int[] boo(inout int[] arr){ > return arr; > } > > int[] arr = [1,2,3]; > > foo(foo(arr)); // ok > boo(boo(arr)); // Error: boo(arr) is not an lvalue Inout arguments don't "break" the lvalueness of a function. In fact, functions aren't lvalues, nor are their return values (which is presumably what you actually meant). The problem isn't that lvalueness is "broken", it's that an inout argument requires an lvalue to be passed and you're not doing it (in either case). Because of that, the second case doesn't work. The first one works fine because the parameter to foo isn't required to be an lvalue. Summary: the problem is in your code, not in the compiler or language. If this explanation isn't clear enough, please post a question about this in digitalmars.D.learn about this. Maybe someone there can explain it better.

Thanks for explanation, it's clear. That's how it's supposed to work and C++ works same way too, though it looks like premature optimization. For me semantics of those 2 snippets is the same int[] boo(inout int[] arr){ return arr; } int[] arr = [1,2,3]; //first - works int[] temp = boo(arr); boo(temp); //second boo(boo(arr)); May be D can be less restrictive then C++ and this issue is just a feature request :-).