Optional argument corner cases, part one

re: Optional argument corner cases, part one

Graham Clark — Tue, 10 May 2011 08:04:03 GMT

I'm a bit confused by the warning the compiler gives you if both the interface and an explicit implementation give a default value for a parameter:

"The default value specified for parameter 'x' will have no effect because it applies to a member that is used in contexts that do not allow optional arguments"

Surely optional arguments *are* allowed in this case, it's just that the one provided on the explicit implementation won't be used?

re: Optional argument corner cases, part one

Graham Clark — Tue, 10 May 2011 07:57:06 GMT

The compiler would also give you an error about using the "public" modifier in your interface!

re: Optional argument corner cases, part one

Pavel Minaev [MSFT] — Tue, 10 May 2011 00:10:03 GMT

@Brett:

VB requires that classes repeat exactly any optional/defaulted arguments from the interfaces they implement - it's considered part of the signature of the method. If you omit the default value on your implementation, the compiler will complain that "there is no matching sub/function on the interface"

The obvious question, then, is why C# couldn't do the same - i.e. refuse to consider method an implementation if values of optional arguments don't match the interface, and then ultimately complain that class didn't properly implement an interface it listed because no matching implementing method was found.

My tentative guess is that this would have broken back-compat for cases where existing C# code implements interfaces defined in VB with optional arguments - since any pre-4.0 C# code wouldn't have used default values in such cases, and hence be broken by 4.0.

re: Optional argument corner cases, part one

Brett — Mon, 09 May 2011 22:20:50 GMT

How did the VB compiler handle these cases?

re: Optional argument corner cases, part one

Brian — Mon, 09 May 2011 21:56:34 GMT

@InBetween: True, but in the case of unreachable code there is a practical situation where a programmer might temporarily want the code unreachable but would still prefer a warning. In particular, this applies in the case where the coder is stuffing a return in the middle of a function for quick and dirty debugging purposes. In contrast to unreachable code, I cannot think of a case where a programmer would want to leave such a useless piece of code in place. It might also apply in the case that a programmer is using Macros...though usually the macros would be used to kill the unreachable code, too.

re: Optional argument corner cases, part one

John Bailo — Mon, 09 May 2011 20:58:11 GMT

Initially I would have wanted this...but seeing it in this use case, I'm sorry but I wish they had stuck to their guns and not tried to make c# more "like VB".

re: Optional argument corner cases, part one

Pavel Minaev [MSFT] — Mon, 09 May 2011 18:47:20 GMT

@ErikF: allowing optional arguments on interfaces lets users of those interfaces omit them when calling methods via interface-typed references.

Not allowing optional arguments on interfaces would also defeat a very major use case for them, which is COM interop (because methods with 10+ arguments, only 1 or 2 of which are required, is fairly common there - if you ever saw Office APIs, you know what I mean).

re: Optional argument corner cases, part one

InBetween — Mon, 09 May 2011 15:58:33 GMT

@Brian

I would gues its the same as having unreachable code.

There is no error per se. The explicit implementation of the interface means that the methods the interface defines can only be called through the interface itself and therefore the optional parameters defined in the class impementing the interface are "unreachable".

re: Optional argument corner cases, part one

Brian — Mon, 09 May 2011 15:26:45 GMT

"This also explains why the compiler gives you a stern warning when you do an explicit interface implementation"

You probably get asked this way too often, but What is the justification for allowing that code to compile with a warning rather than with an error?

Thanks.

re: Optional argument corner cases, part one

ErikF — Mon, 09 May 2011 15:21:20 GMT

Seeing that interfaces can't have any code, I'm trying to understand how allowing optional arguments for an interface method would be helpful. Couldn't you simply forbid optional arguments in interfaces altogether?