Multiple return values...

[Mantis]

08.03.2012 22:08, Manu пишет:
> 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.
> Many maths-y functions return some sort of pair; intersections return 
> (ray, t) or something of that type.
> I'm finding HEAPS of SIMD functions want to return pairs (unpacks in 
> particular): int4 (low, hight) = unpack(someShort8);
> Currently I have to duplicate everyting: int4 low = 
> unpackLow(someShort8); int4 high = unpackHigh(someShort8);
> I'm getting really sick of that, it feels so... last millennium.
>
> 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.
> 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.
> It just means that the returned-to function can find its return 
> values already conveniently in an appropriate register, avoiding 
> memory access.
>
> 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.
> 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.
>
> ... just saying :)

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:
{
     auto t = getSomeTuple(...); // returns Tuple!(float, "x", float, 
"y"), no actual assignment is made
     someVar = t.x^^2 + t.y^^2; // t.x and t.y are just aliases for st1 
and st0
}

With a tuple unpacking syntax suggested by bearophile, this would be 
nicer than any distinct multiple return values syntax, IMO.