Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have worked with many languages that do not generate a method signature based on the return type. I have also worked with one(maybe some?) that do. The ones that don't have given me problems in the past (like here). Why do programming languages generate method signatures without regard to the return type?

Update: I'm referring specifically to compiled statically typed languages

share|improve this question
This is a very unfounded guess, but I'm guessing it has something to do with the difficulty of compiler implementation and/or tool support. – Charles Lambert Apr 23 '11 at 18:08
In Haskell you can use typeclasses to basically make functions that are return type dependent. I <3 Haskell :D :D :D – Thomas Eding Apr 24 '11 at 2:56
up vote 5 down vote accepted

It wouldn't mesh well with typecasting and type hierarchies. If you have two versions of a method, one of which returns type A and one which returns type B, you run into trouble when:

  • A or B are subtypes of each other, and you assign the return value to the one that is the supertype.
  • A and B have a common supertype, and you assign to such a supertype value.

You could get around this with casts, but that would require as much typing as renaming one of the functions would. You could also register a compiler error when the call is ambiguous, in which case the user needs to spend similar amounts of effort.

share|improve this answer
I have worked with languages that include the return type in the signature. Casting all over the place is not an issue as you indicate. In your specific example you would not need to get around this with casts. If A and B (subtypes of C) both have the same operation, then it should be declared in C. If the return type is different for A than for B: In most cases it is trying to return a subtype of C. You simply add another method in the subtype that returns the subtype and implement the version from C to call the one with the specific subtype. Now you don't have to cast all over the place. – Charles Lambert Apr 23 '11 at 17:57
@Charles Lambert: It's not an operation on classes A, B, or C. It's two functions with the same name and parameter list, one of which returns something of type A and the other of which returns something of type B. This question applies to more than just OOP systems, so I answered based on general types and functions. Also, I don't understand what your rebuttal example is intended to accomplish; more detail is required for me to respond to it. – jprete Apr 23 '11 at 19:38
A comment is too short for an example. basically languages that include return type in the signature have already come up with ways to alleviate the problem you are describing. Be it coding convention, or just standard practice. Also of note, not much of what you write would warrant creating methods that differ only in return type. So again, you wouldn't be dealing with this very often – Charles Lambert Apr 23 '11 at 20:30
Would there be any difficulty having a rule that only one "primary" method may be declared for any given argument signature, but an arbitrary number of secondary methods could be declared, and a compiler should perform overloading by first identifying an argument signature for which a primary method exists, and then checking secondary methods in some specified order to see if any such method was an unambiguously better match (or would be usable even if the primary one was not)? – supercat Feb 14 '14 at 22:44

Because you can call a method and not assign its result.

share|improve this answer
Not in every language. – Jörg W Mittag Apr 23 '11 at 8:39
@Jorg Like which language? – Chiron Apr 23 '11 at 14:53
f# is one language. You commonly see foo -> ignore where ignore is a method with return type of unit which is similar to void – Charles Lambert Apr 23 '11 at 18:04
Ada is a better example. That language actually uses return types as part of the signature as well. – Charles Lambert Apr 26 '11 at 0:45

Rule of thumb: strongly typed languages usually bind the method signature to a return type. Weakly typed languages do not.
I do not know C#, but I assume that the problem might be because of the way C# handles generics. It might be creating a totally different method for the generic one, in which case they are really two different methods.

share|improve this answer
I'm curious to which of these strongly-typed languages do you refer? I don't know of any, and I know C++ explicitly forbids resolution to the return type. – greyfade Apr 23 '11 at 4:08
-1 If you are going to give a rule of thumb that is ostensibly wrong with a single example that violates it you should follow that with all of the other examples where the rule is adhered to. – user23157 Apr 23 '11 at 7:05
@greyfade, my point was that in weakly typed languages the assignment is not checked at compile time. Agree, that might not be pertinent here. – CMR Apr 23 '11 at 16:10
Your point is obscured by your inaccurate assertion that "strongly-typed languages usually bind... to a return type". – greyfade Apr 24 '11 at 16:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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