In stack languages (e.g. PostScript, Forth), return values are passed on the stack - zero, one, even a variable number.
Python supports tuples of values there, frequently used "without tuple syntax", but creating a tuple regardless (garbage if not kept but unpacked immediately).

Is there any non-stack language handling multiple return values without overhead?
Handling a variable number of return values without overhead?


2 Answers 2


Modern compilers are quite capable of optimizing a tuple return value so that the result is passed in registers, or in an unpacked form on the stack.

In addition, even when this is not the case, worrying about the overhead is misplaced. If the tuple fits in primary cache, chances are nobody is going to notice the difference.

It was true in 1970 that the programmer had to understand the CPU and memory they were using, because every CPU cycle and every byte of memory was precious. That is why languages such as C were so successful – one can basically predict the machine code that a C compiler generates.

Nowadays the typical programmer only has a vague idea of what the compiler, the optimizer and the CPU actually do. The bottleneck is not in the CPU cycles or bytes of memory, but in the software development time. One should worry about having a programming language that allows one to easily return two values, but not how those two values are returned.

If you happen to be programming an embedded device or a super-computer in which 1% saving of electricity translates to many thousands of dollars in reduced costs, then of course you're playing a different game.

  • $\begingroup$ “Predict machine code”. Years ago I tried figuring out how long a branch took. A loop for(i =0; i<1000000000;++i) {}. It took 3/8ths of a cycle per iteration. Head scratching. It turned out the compiler had unrolled the empty loop eight times and iterated 125 million times. 3 cycles per iteration. $\endgroup$
    – gnasher729
    Commented Jan 29 at 16:41
  • $\begingroup$ I can top that one. I measured the performance of LLVM by compiling s=0; for(i=0;i<n;i++) s++ ... and it was constant time relative to n. The C compiler produced a reasonably looking LLVM loop. But then LLVM said "hey, I know how to add arithmetic series" and converted the thing to s = n(n-1)/2 (also taking care of some overflow thing). $\endgroup$ Commented Jan 30 at 8:18

Swift allows a single return value. However, a “tuple”, including one with unnamed components, is one of the basic types (struct, class, enum, tuple and closure; int, double, string and arrays are really structs) so that is not a problem. For a tuple, obviously it’s a bigger value than a single value and needs more code, but the fact that there is a tuple doesn’t cause overhead.

Now tuples have a fixed number of elements and fixed element types. If you wanted to return a different number of items or items with different types, you would return an enum, which is kind of a mix between C enum and C Union. There’s a bit of overhead because the function must return which kind of enum it is, and possibly more overhead if the size of the enum cases is different.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.