Because functions are mathematical constructs which perform a calculation and return a result. Indeed, much of "under the hood" of not a few programming languages focus solely on one input and one output, with multiple inputs being a thin wrapper around the inputs.

This has not changed because programmers have found out parameters to be awkward constructs that are useful in only a limited set of scenarios. Like with many other things, the support isn't there because the need/demand isn't there.

In mathematics, a "well-defined" function is one where there is only 1 output for a given input (as a side note, you can have only single input functions, and still semantically get multiple inputs using currying).

For multi-valued functions (eg. squared root of a positive integer, for example), it's sufficient to return a collection, or sequence of values.

For the types of functions you're talking about (ie. functions that return multiple values, of different types) I see it slightly differently than you seem to: I see the need/use of out params as a workaround for better design or a more useful data structure. For example, I'd prefer if *.TryParse(...) methods returned a Maybe<T> monad instead of using an out param. Think of this code in F#:

let s = "1"
match tryParse s with
| Some(i) -> // do whatever with i
| None -> // failed to parse

Compiler/IDE/analysis support is very good for these constructs. This would solve much of the "need" for out params. To be completely honest, I can't think of any other methods off-hand where this wouldn't be the solution.

For other scenarios - the ones I can't remember - a simple Tuple suffices.

Some languages, like Python, support multiple return values natively, while some languages like C# support them via their base libraries.

But in general, even in languages that support them, multiple return values are not used often because they're sloppy:

• Functions that return multiple values are hard to name clearly.

• It's easy to mistake the order of the return values

  (password, username) = GetUsernameAndPassword()  
  

  (For this same reason, many people avoid having too many parameters to a function; some even take it as far as to say a function should never have two parameters of the same type!)

• OOP languages already have a better alternative to multiple return-values: classes.
  They're more strongly-typed, they keep the return values grouped as one logical unit, and they keep the names of (properties of) the return values consistent across all uses.

The one place they are pretty convenient is in languages (like Python) where multiple return values from one function can be used as multiple input parameters to another. But, the use-cases where this is a better design than using a class are pretty slim.

In addition to what's already been said when you look at the paradigms used in assembly when a function returns it leaves a pointer to the returning object in a specific register. If they used variable/multiple registers the calling function would not know where to get the returned value(s) if that function was in a library. So that would make linking to libraries difficult and instead of setting an arbitrary number of returnable pointers they went with one. Higher level languages don't quite have the same excuse.

In most languages where functions are supported you can use a function call anywhere where a variable of that type can be used:-

x = n + sqrt(y);

If the function returns more than one value this will not work. Dynamically typed languages such as python will allow you to do this, but, in most cases it will throw up a run time error unless it can work out something sensible to do with a tuple in the middle of an equation.

It does complicate the syntax a little, but there's no good reason at the implementation level not to allow it. Contrary to some of the other responses, returning multiple values, where available, leads to clearer and more efficient code. I can't count how often I have wished I could return an X and a Y, or a "success" boolean and a useful value.

A lot of the use cases where you would have used multiple return values in the past simply aren't necessary anymore with modern language features. Want to return an error code? Throw an exception or return an Either<T, Throwable>. Want to return an optional result? Return an Option<T>. Want to return one of several types? Return an Either<T1, T2> or a tagged union.

And even in the cases where you genuinely need to return multiple values, modern languages usually support tuples or some kind of data structure (list, array, dictionary) or objects as well as some form of destructuring bind or pattern matching, which makes packaging up your multiple values into a single value and then destructuring it again into multiple values trivial.

Here are a few examples of languages that do not support returning multiple values. I don't really see how adding support for multiple return values would make them significantly more expressive to offset the cost of a new language feature.

Ruby

def foo; return 1, 2, 3 end

one, two, three = foo

one
# => 1

three
# => 3

Python

def foo(): return 1, 2, 3

one, two, three = foo()

one
# >>> 1

three
# >>> 3

Scala

def foo = (1, 2, 3)

val (one, two, three) = foo
// => one:   Int = 1
// => two:   Int = 2
// => three: Int = 3

Haskell

let foo = (1, 2, 3)

let (one, two, three) = foo

one
-- > 1

three
-- > 3

Perl6

sub foo { 1, 2, 3 }

my ($one, $two, $three) = foo

$one
# > 1

$three
# > 3

At least the functional languages I know return multiple values straightforwardly without any need of workarounds by tuples (in dynamically typed languages you can use even lists) - also supported by other languages:

f :: Int -> (Int, Int)
f x = (x - 1, x + 1)

// Even C++ have tuples - see Boost.Graph for use
std::pair<int, int> f(int x) {
  return std::make_pair(x - 1, x + 1);
}

In example above the f is a function returning 2 ints.

Similarly ML, Haskell, F#, ... can return data structures as well (pointers are too low-level for most languages). Similarly I have not heard about modern GP language with such restriction:

data MyValue = MyValue Int Int

g :: Int -> MyValue
g x = MyValue (x - 1, x + 1)

Finally the out parameters can be emulated even in functional languages by IORef. There are several reasons why there is no native support for out variables in most languages:

• Unclear semantic. If you have following function is the 0 or 1 printed? I know languages which would print 0 and ones that would print 1 and there are benefits (both in terms of performance as well as matching programmers mental model) to both of them:

  int x;
  
  int f(out int y) {
    x = 0;
    y = 1;
    printf("%d\n", x);
  }
  f(out x);
  

• Non-localized effects. As in example above you can find that you can have a long chain and the innermost function affects the global state. In general it makes it harder to reason what are requirements of function and if the change is legal. Given that most modern paradigms try to either localize the effects (encapsulation in OOP) or eliminate the side-effects (functional programming) it is against those paradigms.

• Being redundant. If you have tuples you have 99% of usage of out parameters and 100% of idiomatic use. If you add pointers to the mix you cover the remaining 1%.

I have troubles naming one language which could not return multiple values by tuple, class or out (and in most cases 2 or more of those methods are allowed).

Well Ruby let your return an array into values, as is:

def aa(value) 
  return [a,b,c] # An array
end

and you can also receive the values straight into a,b,c = aa(20)

One aspect not yet mentioned: in the early days Memory was precious and limited and more return values implied more memory to consume.