Why do we have to name interface method parameters

Question

In C# we have to name the parameters of a method of an interface.

I understand that even if we didn't have to, doing so would help a reader understand the meaning, however in some cases it's not really needed:

interface IRenderable
{
    void Render(GameTime);
}

I would say the above is as readable and meaningful as the below:

interface IRenderable
{
    void Render(GameTime gameTime);
}

Is there some technical reason why names for parameters of methods on an interface are required?

---

^{It's worth noting that the implementation of the interface method can use different names to those in the interface's method.}

Answer 1

One possible reason could be the use of optional parameters.

If we were using an interface, it would be impossible to specify named parameter values. An example:

interface ITest
{
    void Output(string message, int times = 1, int lineBreaks = 1);
}

class Test : ITest
{

    public void Output(string message, int numTimes, int numLineBreaks)
    {
        for (int i = 0; i < numTimes; ++i)
        {
            Console.Write(message);
            for (int lb = 0; lb < numLineBreaks; ++lb )
                Console.WriteLine();
        }

    }
}

class Program
{
    static void Main(string[] args)
    {
        ITest testInterface = new Test();
        testInterface.Output("ABC", lineBreaks : 3);
    }
}

In this implementation, when using the interface, there are default parameters on times and lineBreaks, so if accessing through the interface, it is possible to use defaults, without the named parameters, we would be unable to skip the times parameter and specify just the lineBreaks parameter.

Just an FYI, depending upon whether you are accessing the Output method through the interface or through the class determines whether default parameters are available, and what their value is.

Answer 2

Naming interface method parametres helps with self documentation:

For example ...

interface IRenderable
{
    void Render(TimeSpan gameTime);
}

... says more than:

interface IRenderable
{
    void Render(TimeSpan);
}

Answer 3

I don't see any reason that would make this a technical requirement. But I can think of one particularly good reason:

As you mention, the parameter names are not needed when implementing the interface, and can be easily overridden.
However, when using the interface, imagine the difficulty if no parameters had meaningful names! No intellisense, no hints, nothing but a type? Yuck.
This has got to be the biggest reason that a name is always required.

Answer 4

Ok, this possibility almost seems too frivolous, but -- maybe so when you let Visual Studio implement the interface and stub in properties and methods, it knows what to name the parameters?

On the other hand, VS has no problem generically naming controls...

Answer 5

I can't think of any valid technical reason that interfaces have to have names defined.

I can easily see a situation where the names are auto-implemented like the backing members for auto-implemented properties are today.

However, I think that there are probably 3 main reasons why they have been needed:

1) It was probably substantially easier to implement interface validation in the compiler using the same rules as actual methods. Since it was only relatively recently that auto-implemented properties were introduced, I suspect this is a non-trivial compiler change.

2) For those languages that support auto-creation of the interface members in the implementing class (i.e. VB), it is probably much easier to create the interface implementation using pre-defined names than trying to create names on the fly.

3) Since an interface can be exposed outside of the defining application, names remove the ambiguity associated with an ill-defined interface.

For example, attempting to implement an interface method of:

void Foo(string, string, int)

Would most likely lead to substantially more confusion than your self-documenting example. However, this is really more of an interface usability issue than a technical one, although one could argue that if the interface is unusable, there is an underlying technical issue.