Multiple return values...

[Manu]

On 9 March 2012 00:29, Mantis <mail.mantis.88 at gmail.com> wrote:

> 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.
>

One more little detail too, a Tuple is just a standard template.
Are the suggestion that the LANGUAGE definite case sensitive behavioural
tweaks, relying on the definition of a specific library defined template?

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...

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120309/a1a45222/attachment-0001.html>