On 9 March 2012 17:57, Timon Gehr <[email protected]> wrote: > On 03/09/2012 04:38 PM, Manu wrote: > >> On 9 March 2012 16:27, Timon Gehr <[email protected] >> <mailto:[email protected]>> 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? >> > > void main(){ > int a,b; > (a,b)=2; > assert(a==0); > assert(b==2); > > } > > >> 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. >> > > You are probably confusing the tuple concept with a Phobos 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. >> > > This is simple pattern matching.
I'm not sure what you mean by this? > 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. >> > > What you propose is tuple syntax. > What I mean is this: retTuple = func(); someStruct.x = retTuple[0]; y = retTuple[1]; // retTuple[2] is ignored, but the intent is not clear in the code as it was in my prior example, I like how my prior example makes this intent explicit int err = retTuple[3]; This is pretty horrible. Surely you can see why I want to be able to arbitrarily assign the return values directly? That's what I mean by 'abuse of the tuple syntax', but if that's not what you mean, then show me an example of the usage of your suggestion?
