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