Multiple return values...
Martin Nowak
dawg at dawgfoto.de
Mon Mar 12 14:39:21 PDT 2012
> Is this basically like saying it'll never happen?
> There is already a pending pull request implementing the syntax, that
> addresses half of the feature straight up.. codegen can come later, I
> agreed earlier that it is of lesser importance.
> You don't see the immediate value in a convenient MRV syntax? It would
> improve code clarity in many places, and allow the code to also be more
> efficient down the road.
>
The tuple unpacking feature has nothing to do with MRV.
Please don't conflate them, it creates a lot of confusion.
Using registers to full extend look really nice but there
are some reasons MRV is not going to happen any time soon.
- Departing from platform ABI's will put us on an isle
where we need our own compiler backends, debuggers and
maybe even linkers and OSes.
- Your favorite compiler should be great at inlining so
chained function calls could have ZERO overhead passing
return values.
- It is not very efficient to combine MRV with tuples that
have a contiguous memory layout. Instead of in-place NRVO
this would be 'callee stack->registers->caller stack'.
More information about the Digitalmars-d
mailing list