Why multiple return values is not a common thing?

Question

I would like to ask a question about multiple return values, why this construct is not preferrable in programming languages (conceptual and/or technical difficulties). I've heard something about stack frames and how they reserve memory for return value and variable return values could make this problematic, but if someone could explain this better, this would be much appreciated.

In conctanetative languages (like FORTH), having multiple return values from a function is a common and very useful thing, and I imagine something like this in java/c-like languages would be useful too (a very basic example):

x, y = multRet(5);
multret(int x) {
    return x+1;
    return x+2;
    exit;
}

To clarify: I am not asking how to return multiple values (this is a known question with known answers), but I want to get a clarification about why this practice is not common in programming languages.

Answer 1

Functions are traditionally thought of as returning a single value - in math. Of course several values form a tuple, but oftentimes in math we are dealing with real-valued functions. I suspect that this origin of functions is the reason why multiple return values are not so common. That said, it's easy to emulate them in several ways (by returning a tuple, or by having several output parameters, i.e. ones passed by reference), and some common modern languages (such as Python) natively support this construction.

Answer 2

Having multiple return values is preferable. Lacking them is bad design, plain and simple. However, we should clear up the misconception that such a thing even exists in the sense you are thinking of.

In languages based on the typed lambda-calculus (the progenitor programming languages), e.g. ML-family, Haskell, a function (lambda abstraction) only accepts a single argument and "returns" (more formally, evaluates to) a single result. So how can we create a function that seems to take or return multiple values?

The answer is that we can "glue" values together by using product types. If A and B are both types, then the product type $A \times B$ contains all tuples of the form $(a, b)$, where $a: A$ and $b: B$.

Thus, to create a function multiply that multiplies two integers together, we give it the type multiply: int * int -> int. It accepts a single argument which happens to be a tuple. Likewise, a function split that splits a list into two would have type split: a list -> a list * a list.

Maybe 30 years ago implementation was a valid concern in including such a feature. According to the C calling convention cedl (and it is just that, a convention - no god ordained it), the return value is stored in a special register, usually EAX. Certainly, this is extremely fast to read and write, so the idea has some merit.

But it is too limiting, as you point out, and there is no reason we need to follow this rule nowadays. For example, we could instead use the following policy: for a small number of return values, use a set of specified registers (we have more registers for use now than in the 80s). For larger data, we could return a pointer to a location in memory. I don't know what's best; I'm not a compiler writer. But the archaic C calling convention should have no influence on the semantics of modern languages.

Answer 3

Syntax is not necessary when simple patterns do the job better and your proposed syntax would be historically confusing to a lot of people. This means your syntax is hard to learn and will lead to problems when people switch between your language and others.

The simple pattern that solves this problem is defining a Variable named "returnValue" at the start of your method and then assign values to it. If you need multiple values, then simply use a collection of some sort and add the values instead. Then return this Variable. Problem solved.

Your syntax would mean that you would by default have to handle collections. This is frustrating for function that only return 1 value.

And what if someone does something wrong ? Eg.

x, y = multRet(5);
multret(int x) {
    return x+1;
    exit;
}

or

x = multRet(5);
multret(int x) {
    return x+1;
    return x+1;
    exit;
}

Is the compiler supposed to catch that? What if you have a loop?

At best this would be syntactic sugar. Something that doesn't add new features but instead only makes current patterns more comfortable and shorter in code.

At worst this would lead to horrible, horrible error in code. Null pointer exception in masses.

Answer 4

It is mostly because of syntactical reasons; in your own example the first return statement would return one value and return, and never reach the second return statement.

There are nowadays a few languages that allow returning a tuple, that is zero, one or more values of arbitrary types, packaged together to be a single value. Still, they are returning one value, just a slightly more complicated value. Usually such languages would also have a way to assign a tuple to zero, one or more matching variables, often with an easy way to ignore some elements of the tuple. This could look like this:

Assign tuple to another tuple:

x = multRet(5); // x is a variable of type tuple (int, int)
multret(int x) {
    return (x+1, x+2);
}

(x, y) = multRet(5); // x, y are variables of type int
multret(int x) {
    return (x+1, x+2);
}

(x, _) = multRet(5); // x is a variable of type int, second component ignored. 
multret(int x) {
    return (x+1, x+2);
}

That syntax wouldn't be compatible with C, where (x, y) is a comma expression in parentheses. On the other hand, receiving two values is much easier than in C, where you either pass the two values using pointers, or you declare a struct for this purpose, fill it, and return it. Using pointers, the third example where the caller is only interested in one value is a pain, so this method of returning tuples is very useful.