48

What is the Method Signature in the following

int DoSomething(int a, int b);

Return type is a part of signature or not???

BoltClock
  • 700,868
  • 160
  • 1,392
  • 1,356
Usman
  • 3,200
  • 3
  • 28
  • 47

7 Answers7

84

Return type is not part of the method signature in C#. Only the method name and its parameters types (but not the parameter names) are part of the signature. You cannot, for example, have these two methods:

int DoSomething(int a, int b);
string DoSomething(int a, int b);

To be clear: Methods cannot be overloaded based on their return type. They must have a unique name, unique parameter types, or pass their arguments differently (e.g. using out or ref).

Edit: To answer your original question, the method signature for your method is:

DoSomething(int, int)

Note that this all applies to normal methods. If you're talking about delegates, then you should see keyboardP's answer. (Short version: return type IS part of the signature for a delegate).

Wael Alshabani
  • 1,495
  • 1
  • 15
  • 16
ean5533
  • 8,884
  • 3
  • 40
  • 64
  • @adamjmarkham: You can only do it when overriding in a subclass, not "depending on what the method does". And I'm pretty sure that the return type is *not* part of the signature. – BoltClock Jan 10 '12 at 18:48
  • return type is not part of the method signature my padawan. – DarthVader Jan 10 '12 at 18:48
  • 1
    This answer really needs to unmarked as accepted because it is not correct. Eric Lippert's answer below correctly defines the elements that constitute a method's signature. – 0b101010 Apr 17 '15 at 11:00
  • @0b101010 Everything in my answer is factually correct. Eric's answer is also correct and is certainly more comprehensive (unsurprising given his background), but that doesn't make this answer any less accurate. – ean5533 Apr 17 '15 at 14:25
  • @ean5533 Respectfully I disagree. You state "They must have a unique name or unique parameter types." There is no mention of the means by which arguments are passed to parameters. This is separate to the parameter type itself. A subtle but important point. Perhaps a small update to the answer might help future readers? Given that this is the accepted answer they may not bother to read down to Eric's answer below. – 0b101010 Apr 17 '15 at 14:51
  • @0b101010 I'm not entirely sure what you mean by "the means by which arguments are passed to parameters", but I think it's irrelevant. The sentence you're quoting is clearly scoped to discussions about method overloading, and again, the statement is correct: two methods cannot live in the same type unless they have unique names or unique parameter types. Eric's answer confirms this. – ean5533 Apr 17 '15 at 17:00
  • @ean5533 This is incorrect. Methods can also be overloaded by argument passing convention (either by value or by reference). This is easy demonstrated by putting methods with the following signatures in the same type `DoSomething(int i)` and `DoSomething(ref int i)`. It will build without any problem even though the two methods have the same name `DoSomething` and same parameter type `int`. Give it a try. – 0b101010 Apr 17 '15 at 19:19
  • @0b101010 Ah, now I understand what you're saying. You're correct, I omitted out/ref-ness in my list of distinguishing characteristics. I will update my answer to include that. – ean5533 Apr 18 '15 at 14:54
  • @ean5533 Great. I obviously didn't explain myself very well at first. Worth noting that you can only overload based on the means of passing (i.e. by value or by reference). Both `out` and `ref` parameters are passed by reference so you cannot have two methods which only differ by `out` and `ref`. See Eric's answer for the details. – 0b101010 Apr 19 '15 at 08:50
56

Is the return type is a part of signature or not?

It depends on why you are asking the question. Why do you care?

There are two definitions of method signature. The C# language definition does not include the return type, and uses the signature of the method to determine whether two overloads are allowed. Two methods with the same signature are not allowed in a type. Since C# does not consider the return type to be a part of the signature, C# does not allow two methods that differ only in return type to be declared in the same type.

The CLR, however, does include the return type in the signature. The CLR allows for two methods to be in the same type that differ only in return type.

To be more specific: in C# the signature consists of the methods:

  • name
  • number of type parameters
  • number of formal parameters
  • type of each formal parameter
  • out/ref/value-ness of each formal parameter

with the following additional notes:

  • generic type parameter constraints are not part of the signature
  • return type is not part of the signature
  • type parameter and formal parameter names are not part of the signature
  • two methods may not differ only in out/ref

In the CLR the signature consists of:

  • name
  • number of type parameters
  • number of formal parameters
  • type of each formal parameter including modopts and modreqs
  • return type including modopts and modreqs
  • ref/value-ness of each formal parameter

Note that the CLR does not distinguish between "ref int" and "out int" at all when considering signatures. Note that the CLR does distinguish between modopt/modreq types. (The way that the C# compiler deals with modopt/modreq types is too complex to summarize here.)

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 4
    I've been googling and found nothing as for why did C# team decide the return type to not be part of the signature? Performance issues only? Could you shed some light? tks – Luis Filipe Aug 14 '12 at 12:32
  • Hi , I would like to ask same question as Luis fillipe . – Mudassir Hasan Mar 23 '15 at 19:27
  • 2
    @mmhasannn: Overloads must differ in signature. If the return type is part of the signature then you can have two methods that differ only in return type. That massively complicates overload resolution. – Eric Lippert Mar 23 '15 at 20:57
  • Isn't this complexity already solved in the CLR? Couldn't C# leverage the CLR implementation? – Luca Cremonesi Mar 24 '15 at 14:44
  • 6
    @LucaCremonesi: Not at all. Overload resolution isn't a feature of the CLR. Overload resolution is a feature of *languages*, not of *runtimes*. – Eric Lippert Mar 24 '15 at 15:46
  • What is formal parameter? – Denis535 Aug 20 '18 at 14:42
  • 3
    @wishmaster35: If you have a method with signature `string F(int x)` then `x` is the *formal parameter* and `T` is the *type parameter* and `int` is the *formal parameter type*. When you call it: `F(123)` then 123 is the *argument* or *actual parameter*, and `double` is the *type argument*. – Eric Lippert Aug 20 '18 at 16:15
  • @EricLippert I think that the order of the parameters is part of the signature. Since we can have two methods `int DoSomething(string a, int b);` and `int DoSomething(int b, string a);`. What do you think? – Best_fit Nov 19 '21 at 13:37
14

From MSDN:

A return type of a method is not part of the signature of the method for the purposes of method overloading. However, it is part of the signature of the method when determining the compatibility between a delegate and the method that it points to.

To clarify, in your example the return type is not part of the signature. However, when you're matching the signature of a delegate, it is considered part of the signature. From MSDN:

Any method that matches the delegate's signature, which consists of the return type and parameters, can be assigned to the delegate. This makes is possible to programmatically change method calls, and also plug new code into existing classes. As long as you know the delegate's signature, you can assign your own delegated method.

So I believe it's based on context. Most of the time, and as shown in your code, the return type is not part of it. However, in the context of delegation, it is considered part of it.

keyboardP
  • 68,824
  • 13
  • 156
  • 205
13

From MSDN:

The signature of a method consists of the name of the method and the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. The signature of a method specifically does not include the return type

Edit: That is from old documentation. It seems the definition of 'signature' has changed since then. Now a method has two different signatures, one for the purpose of overloading and one for the purposes of determining delegate compatibility. See keyboardP's answer below for more details.

Sean U
  • 6,730
  • 1
  • 24
  • 43
  • @gdoron If you split the vote scores you can see that someone downvoted every answer on the page. Go figure. Edit: And now they downvoted the question too. – ean5533 Jan 10 '12 at 18:55
  • @gdoron - Regardless, keyboardP's answer, which references much more recent documentation, is much better than mine. – Sean U Jan 10 '12 at 18:56
5
DoSomething(int a, int b);

is the method signature,

int is the return type.

take a look at this :Signatures and overloading

DarthVader
  • 52,984
  • 76
  • 209
  • 300
0

In the case when method have generic arguments understanding of signature becomes more confusing.

Generic types declaring on class level are considered as normal types.

But generic types declaring on method level are considered as index in method's generic arguments.

For example these all methods have different signatures.

class MyClass<TValue>
{
    public void F(TValue v) { }       // generics: 0, arg: TValue
    public void F<X>(TValue v) { }    // generics: 1, arg: TValue
    public void F<X, Y>(TValue v) { } // generics: 2, arg: TValue

    public void F<X>(X v) { }    // generics: 1, arg: 0
    public void F<X, Y>(X v) { } // generics: 2, arg: 0
    public void F<X, Y>(Y v) { } // generics: 2, arg: 1
}
Denis535
  • 3,407
  • 4
  • 25
  • 36
0

The signature does not contain the return type. Neither the parameter names. In your case it would be DoSomething(int, int)

MatthiasG
  • 4,434
  • 3
  • 27
  • 47