On 9 March 2012 16:27, Timon Gehr <timon.g...@gmx.ch> wrote: > On 03/09/2012 01:23 AM, Manu wrote: > >> I can imagine syntax using parentheses, but I don't think I'm qualified >> to propose a robust syntax, I don't know enough about the finer details >> of the grammar. >> Perhaps if other people agree with me, they could present some creative >> solutions to the syntax? >> >> I imagine something like: >> auto (x, y) = func(); // specify auto for all results? >> float (x, y) = func(); // specify explicit type for all results? >> (int x, float y) = func; // explicitly type each result? >> > > This works, and Kenji Hara has already implemented appropriate parser > extensions. > > int x; ... (x, float y) = func(); // assign to predeclared variable(/s)? >> (x, , z) = func(); // ignore the second result value (elimination of the >> >> second result's code path) >> >> > Those two would work, but (x,y) = func(); conflicts with the comma > operator. (I'd prefer (,) to be a tuple constructor though.) >
You think so? Within that context, I would think the coma could be reinterpreted however it likes. The usual use of the coma operator makes no sense in this context? These last 2 examples are what I see as being the most important part, and the precise reason that it SHOULDN'T be a tuple. The ability to directly assign results to explicit (existing) variables, and to ignore some/all of the return values, is a fundamental feature of the *concept* of return values universally. I see this as basically the whole point. Another example: (someStruct.x, y, , int err) = func(); In this example, I assign the x result to a struct, y assigns to some existing local, we ignore z because we can (visually states our intent, would be hidden through use of a tuple), and we declare an int to capture a potential error in place. If we were abusing the tuple syntax, we would need additional lines following the call to assign the rvalues out to their appropriate places, which is unnecessary spaghetti.
