<div class="gmail_quote">On 9 March 2012 00:29, Mantis <span dir="ltr"><<a href="mailto:mail.mantis.88@gmail.com">mail.mantis.88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
08.03.2012 22:08, Manu пишет:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I find myself really wishing for proper multiple return values almost every day, particularly when I work with maths heavy code, and especially for efficiently returning error codes in functions I'd rather not throw from.<br>

Many maths-y functions return some sort of pair; intersections return (ray, t) or something of that type.<br>
I'm finding HEAPS of SIMD functions want to return pairs (unpacks in particular): int4 (low, hight) = unpack(someShort8);<br>
Currently I have to duplicate everyting: int4 low = unpackLow(someShort8); int4 high = unpackHigh(someShort8);<br>
I'm getting really sick of that, it feels so... last millennium.<br>
<br>
The point of 'proper' multiple return values is to return each value in registers, in its own register type, using exactly the same register assignment pattern as when passing args TO functions.<br>
I don't think this causes any side effects to the ABI, since the arg registers are already volatile across function calls in the first place.<br>
It just means that the returned-to function can find its return values already conveniently in an appropriate register, avoiding memory access.<br>
<br>
People argue I should return a tuple, but this isn't really the same, it has hidden implications that complicate the optimisation potential. For instance, tuples have an implicit structure/memory layout which can't be ignored, whereas return values don't have memory allocated, ie, you can't take the address of a return value without first assigning it to some local syntactically.<br>

The implementation of efficient tuple return values would be much more complicated I would imagine too, and the rules are less clear; I can't intuitively presume what behaviour returning a tuple of different things should actually have in terms of register assignment. I also know precisely how multiple return values should work, because it is exactly the same as passing arguments to the function, but in reverse.<br>

<br>
... just saying :)<br>
</blockquote>
<br></div></div>
I'd like to see this as a part of tuple improvement, since tuples may hold additional compile-time information. This would make it possible to write efficient code, and at the same time have the ability to reference tuple components by name rather than position. For example:<br>

{<br>
    auto t = getSomeTuple(...); // returns Tuple!(float, "x", float, "y"), no actual assignment is made<br>
    someVar = t.x^^2 + t.y^^2; // t.x and t.y are just aliases for st1 and st0<br>
}<br>
<br>
With a tuple unpacking syntax suggested by bearophile, this would be nicer than any distinct multiple return values syntax, IMO.<br>
</blockquote></div><br><div>One more little detail too, a Tuple is just a standard template.</div><div>Are the suggestion that the LANGUAGE definite case sensitive behavioural tweaks, relying on the definition of a specific library defined template?</div>
<div><br>The only way I can imagine such an implementation actually working in a well defined way, is if the concept were applied to all structures-by-value universally, which leads straight back to the rant in my prior post...</div>
<div><br></div><div>I wonder if the details of the implementation would be considerably harder to implement given this approach too (it sounds way loaded with issues to me), and particularly so for GDC?</div>