Definition of a method signature?

Question

What is the correct definition of a method signature (or a signature of a method)?

On google, I find various definitions:

It is the combination of the method name and the parameter list

Does that mean method signature = method name + argument list? Then I do not see difference between "method" and "method signature".

If I have a method:

public void Foo(int x, int y) { ... }

Would my method signature be one of the following, or neither?

• Foo
• Foo(int, int)
• Foo(int x, int y)
• Foo(34, 78)

How am I suppose to answer if someone ask me what is the method signature of the method?

Refugee

Recommend you read section 3.6 of the C# Language Specification (v 4.0) which provides a precise answer regarding method signatures. It also explains signatures for instance contstructors, indexers and operators. There are also several helpful examples. – Lazo

Answer 1

There are a number of correct answer here which define the method signature as the method name, generic arity, formal parameter arity and formal parameter types and kinds, but not the return type or "params" modifier.

Though that is correct, there are some subtleties here. The way the C# language defines method signature is different from the way the CLR defines method signature, and that can lead to some interesting problems when interoperating between C# and other languages.

For the CLR, a method signature consists of the method name, generic arity, formal parameter arity, formal parameter types and kinds, and return type. So there is the first difference; the CLR considers return type.

The CLR also does not consider "out" and "ref" to be of different formal parameter kinds; C# does.

The CLR also has an interesting feature called "optional and required type modifiers", usually called "modopts" and "modreqs". It is possible to annotate a type in a method signature with another type that tells you about the "main" type. For example, in C++ these are two different signatures:

void M(C const & x);
void M(C & x);

Both signatures define a method M that takes a parameter of type "reference to C". But because the first one is a const reference and the second is not, the C++ language considers these to be different signatures. The CLR implements this by allowing the C++/CIL compiler to emit a modopt for a special "this is const" type on the formal parameter type.

There is no way to read or set a mod in C#, but the C# compiler nevertheless knows about them and will honour them in some ways. For example, if you had a public virtual method declared in C++/CIL like:

void V(C const * x)

and you override that in a derived class written in C#, the C# compiler will not enforce const correctness for you; the C# compiler has no idea what the const modopt means. But the C# compiler will ensure that the overriding method is emitted into metadata with the modopt in place. This is necessary because the CLR requires signatures of overriding and overridden methods to match; the compiler has to obey the CLR rules for signature matching, not the C# rules.

Kylander

Are these mods used for things other than const? – Banville

@configurator: Yes. "const" is a modopt -- optional, because if you don't understand it, no harm done. Const correctness is not a guarantee of good behaviour, it is a statement of intention. "volatile" is a modreq -- required, because if you don't understand it, you can break something. "volatile" is a guarantee, that every access to this thing will have acquire and release semantics; if you don't understand that then you have to not touch the volatile thing. – Kylander

Used for other things? Yes, see ikvm, where I recently learned about these modifiers: weblog.ikvm.net/… – Rehearing

"the CLR considers return type." I guess that means the same as in Java, namely that backward compatibility may be broken if one changes the return value, fx from void to <some value>: you will not get compile errors, but the method will potentially not be found at runtime (if we are dealing with multiple projects and not all are recompiled). – Duress

Answer 2

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, nor does it include the params modifier that may be specified for the right-most parameter.

The important part here is that the return type of a method does not belong to its signature. So you can't overload methods which differ by return type only!

Amrita

From your reference in MSDN: signature includes the output of a method, but you said does not include return type. So a signature include return value (as in output), but not return type? – Refugee

I think you mix up the return value and output parameters. The return type does not belong to the signature. But output parameters do belong to the signature (see out parameter modifier, msdn.microsoft.com/en-us/library/ee332485.aspx) – Amrita

you can't even have methods only differing by return type, because there will be ambiguity between them. the compiler won't take – Clabo

Now according to MSDN, return type is part of the signature, but you're correct that you can't overload by just the return type. "Methods are declared in a class, struct, or interface by specifying the access level such as public or private, optional modifiers such as abstract or sealed, the return value, the name of the method, and any method parameters. These parts together are the signature of the method." – Hesione

Answer 3

Method signature is the set of attributes of a method that a compiler can use to identify the method.

The attrbutes are: Method name, number of parameters, parameter type and order of parameters.

Example of diferent method signatures:

Foo()
Foo(int)
Foo(String)
Foo(int, string)
Foo(string, int)

All of these methos are diferent, and when you call them in code the compiler can infer which method are you intent to execute using the method signature.

Don't forget the scope of the methods in modular programming...

Cosher

Always love these simple answers. Thanks – Odyl

Answer 4

The method signature includes following items:

• The name of the method.
• The number of parameters.
• The data types and order of the parameters.

Note: The return type is not part of the signature.

Reproachless

According to MSDN, return type is part of the signature, but changing just the return type is not enough for overloading. "Methods are declared in a class, struct, or interface by specifying the access level such as public or private, optional modifiers such as abstract or sealed, the return value, the name of the method, and any method parameters. These parts together are the signature of the method." – Hesione

Answer 5

In your example above the method signature is Foo(int x, int y). This is important to know because in languages which allow method overloading (such as C# and Java), the method name will be the same, but the signature must be different.

Inbreed

Answer 6

Section 3.6 of the C# Language Specification (v 4.0) provides the most precise answer regarding method signatures:

The signature of a method consists of the name of the method, the number of type parameters and the type and kind (value, reference, or output) of each of its formal parameters, considered in the order left to right. For these purposes, any type parameter of the method that occurs in the type of a formal parameter is identified not by its name, but by its ordinal position in the type argument list of the method. The signature of a method specifically does not include the return type, the params modifier that may be specified for the right-most parameter, nor the optional type parameter constraints.

Lazo

Answer 7

MSDN article "Methods (C# Programming Guide)"

tells:

Methods are declared in a class or struct by specifying the access level such as public or private, optional modifiers such as abstract or sealed, the return value, the name of the method, and any method parameters. These parts together are the signature of the method.

And further on, what I have not seen amongst other answers:

"Note

"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"

Wynd