11

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

Improve this question
2
  • 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
    Commented Apr 23, 2011 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
    Commented Apr 24, 2011 at 2:56

3 Answers 3

Reset to default
5

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.

Improve this answer
4
  • 1
    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
    Commented Apr 23, 2011 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
    Commented Apr 23, 2011 at 19:38
  • A comment is too short for an example. pastebin.com/JR39PKs0 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
    Commented Apr 23, 2011 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
    Commented Feb 14, 2014 at 22:44
3

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

Improve this answer
4
  • 3
    Not in every language.
    – Jörg W Mittag
    Commented Apr 23, 2011 at 8:39
  • @Jorg Like which language?
    – Chiron
    Commented Apr 23, 2011 at 14:53
  • 1
    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
    Commented Apr 23, 2011 at 18:04
  • Ada is a better example. That language actually uses return types as part of the signature as well.
    – Charles Lambert
    Commented Apr 26, 2011 at 0:45
-4

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.

Improve this answer
4
  • 1
    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
    Commented Apr 23, 2011 at 4:08
  • 2
    -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
    Commented Apr 23, 2011 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
    Commented Apr 23, 2011 at 16:10
  • Your point is obscured by your inaccurate assertion that "strongly-typed languages usually bind... to a return type".
    – greyfade
    Commented Apr 24, 2011 at 16:18

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.