Why isn't the overloading with return types allowed? (at least in usually used languages)

Question

I don't know about all programming languages, but it's clear that usually the possibility of overloading a method taking into consideration its return type (assuming its arguments are the same number and type) is not supported.

I mean something like this:

 int method1 (int num)
 {

 }
 long method1 (int num)
 {

 }

It's not that it's a big issue for programming but on some occasions I would have welcome it.

Obviously there would be no way for those languages to support that without a way to differentiate what method is being called, but the syntax for that can be as simple as something like [int] method1(num) or [long] method1(num) that way the compiler would know which would be the one that would be called.

I don't know about how compilers work but that doesn't look to be that difficult to do, so I wonder why something like that isn't usually implemented.

Which are the reasons why something like that is not supported?

Answer 1

It complicates type checking.

When you only permit overloading based on argument types, and only permit deducing variable types from their initialisers, all of your type information flows in one direction: up the syntax tree.

var x = f();

given      f   : () -> int  [upward]
given      ()  : ()         [upward]
therefore  f() : int        [upward]
therefore  x   : int        [upward]

When you permit type information to travel in both directions, such as deducing a variable’s type from its usage, you need a constraint solver (such as Algorithm W, for Hindley–Milner type systems) in order to determine the type.

var x = parse("123");
print_int(x);

given      parse        : string -> T  [upward]
given      "123"        : string       [upward]
therefore  parse("123") : ∃T           [upward]
therefore  x            : ∃T           [upward]
given      print_int    : int -> ()    [upward]
therefore  print_int(x) : ()           [upward]
therefore  int -> ()    = ∃T -> ()     [downward]
therefore  ∃T           = int          [downward]
therefore  x            : int          [downward]

Here, we needed to leave the type of x as an unresolved type variable ∃T, where all we know about it is that it’s parseable. Only later, when x is used at a concrete type, do we have enough information to solve the constraint and determine that ∃T = int, which propagates type information down the syntax tree from the call expression into x.

If we failed to determine the type of x, either this code would be overloaded as well (so the caller would determine the type) or we would have to report an error about the ambiguity.

From this, a language designer can conclude:

• It adds complexity to the implementation.

• It makes typechecking slower—in pathological cases, exponentially so.

• It’s harder to produce good error messages.

• It’s too different from the status quo.

• I don’t feel like implementing it.

Answer 2

Because it's ambiguous. Using C# as an example:

var foo = method(42);

Which overload should we use?

Ok, perhaps that was a bit unfair. The compiler can't figure out what type to use if we don't tell it in your hypothetical language. So, implicit typing is impossible in your language and there goes anonymous methods and Linq along with it...

How about this one? (Slightly redefined signatures to illustrate the point.)

short method(int num) { ... }
int method(int num) { ... }

....

long foo = method(42);

Should we use the int overload, or the short overload? We simply don't know, we'll have to specify it with your [int] method1(num) syntax. Which is a bit of a pain to parse and write to be honest.

long foo = [int] method(42);

The thing is, it's surprisingly similar syntax to a generic method in C#.

long foo = method<int>(42);

(C++ and Java have similar features.)

In short, language designers chose to solve the problem in a different way in order to simplify the parsing and enable much more powerful language features.

You say you don't know much about compilers. I'd highly recommend learning about grammars and parsers. Once you understand what a context free grammar is, you'll have a much better idea about why ambiguity is a bad thing.

Answer 3

All language features add complexity, so they have to provide enough benefit to justify the inevitable gotchas, corner cases, and user confusion that every feature creates. For most languages, this one simply doesn't provide enough benefit to justify it.

In most languages, you would expect the expression method1(2) to have a definite type and a more or less predictable return value. But if you allow overloading on return values, that means it's impossible to tell what that expression means in general without considering the context around it. Consider what happens when you have a unsigned long long foo() method whose implementation ends with return method1(2)? Should that call the long-returning overload or the int-returning overload or simply give a compiler error?

Plus, if you have to help the compiler by annotating the return type, not only are you inventing more syntax (which raises all the aforementioned costs of allowing the feature to exist at all), but you're effectively doing the same thing as creating two differently-named methods in a "normal" language. Is [long] method1(2) more intuitive than long_method1(2)?

---

On the other hand, some functional languages like Haskell with very strong static type systems do allow this sort of behavior, because their type inference is powerful enough that you rarely need to annotate the return type in those languages. But that's only possible because those languages truly enforce type safety, more so than any traditional language, along with requiring all functions to be pure and referentially transparent. It's not something that would ever be feasible in most OOP languages.

Answer 4

It is available in Swift and works fine there. Obviously you cannot have an ambiguous type on both sides so it has to be known on the left.

I used this in a simple encode/decode API.

public protocol HierDecoder {
  func dech() throws -> String
  func dech() throws -> Int
  func dech() throws -> Bool

That means that calls where parameter types are known, such as an init of an object, work very simply:

    private static let typeCode = "ds"
    static func registerFactory() {
        HierCodableFactories.Register(key:typeCode) {
            (from) -> HierCodable in
            return try tgDrawStyle(strokeColor:from.dech(), fillColor:from.dechOpt(), lineWidth:from.dech(), glowWidth: from.dech())
        }
    }
    func typeKey() -> String { return tgDrawStyle.typeCode }
    func encode(to:HierEncoder) {
        to.ench(strokeColor)
        to.enchOpt(fillColor)
        to.ench(lineWidth)
        to.ench(glowWidth)
    }

If you're paying close attention, you will notice the dechOpt call above. I found out the hard way that overloading the same function name where the differentiator was returning an optional was too prone to error as the calling context could introduce an expectation it was an optional.

Update - note on types

One important point about Swift which makes it work well there but not in C++ is that Swift requires explicit numeric type conversion.

This is one of their decisions that abandons C compatibility and makes for vastly more robust coding than C++. It also answers the most common objection to return type overloading.

Answer 5

int main() {
    auto var1 = method1(1);
}