ChatGPT解决这个技术问题 Extra ChatGPT

Why are C# 4 optional parameters defined on interface not enforced on implementing class?

I noticed that with the optional parameters in C# 4 if you specify an optional parameter on an interface you don,t have to make that parameter optional on any implementing class:

public interface MyInterface
{
    void TestMethod(bool flag = false);
}

public class MyClass : MyInterface
{
    public void TestMethod(bool flag)
    {
        Console.WriteLine(flag);
    }
}

and therefore:

var obj = new MyClass();        
obj.TestMethod(); // compiler error

var obj2 = new MyClass() as MyInterface;
obj2.TestMethod(); // prints false

Does anyone know why optional parameters are designed to work this way?

On one hand I suppose the ability to override any default values specified on the interfaces is useful though to be honest I'm not sure if you should even be able to specify default values on the interface as that should be an implementation decision.

On the other hand, this disconnect means you can't always use the concrete class and the interface interchangeably. This of course, wouldn't be a problem if the default value is specified on the implementation, but then if you're exposing your concrete class as the interface (using some IOC framework to inject the concrete class for instance) then really there's no point having the default value as the caller will have to always provide it anyway.

Because they are optional?
But you can cast the object instance to MyInterface and call it with the optional parameter: ((MyInterface)obj).TestMethod();.
@oded - but if you say this parameter is optional on the contract, why do you allow the implementer to not make it optional? doesn't that just cause confusion to anyone looking to use the contract?
I think in this case you can say that the parameter is optional in implementing, not in calling the implementing methods.When you call the method in the class you have to follow the class rules (the parameter is not optional in the class so you can't call the method without it), and in the second hand when you implement the interface you have to follow the interface rules,so you can override the methods with/without optional parameters. Just an opinion.
More detail problem explanation here -> geekswithblogs.net/BlackRabbitCoder/archive/2010/06/17/…

E
Eric Lippert

UPDATE: This question was the subject of my blog on May 12th 2011. Thanks for the great question!

Suppose you have an interface as you describe, and a hundred classes that implement it. Then you decide to make one of the parameters of one of the interface's methods optional. Are you suggesting that the right thing to do is for the compiler to force the developer to find every implementation of that interface method, and make the parameter optional as well?

Suppose we did that. Now suppose the developer did not have the source code for the implementation:

// in metadata:
public class B 
{ 
    public void TestMethod(bool b) {}
}

// in source code
interface MyInterface 
{ 
    void TestMethod(bool b = false); 
}
class D : B, MyInterface {}
// Legal because D's base class has a public method 
// that implements the interface method

How is the author of D supposed to make this work? Are they required in your world to call up the author of B on the phone and ask them to please ship them a new version of B that makes the method have an optional parameter?

That's not going to fly. What if two people call up the author of B, and one of them wants the default to be true and one of them wants it to be false? What if the author of B simply refuses to play along?

Perhaps in that case they would be required to say:

class D : B, MyInterface 
{
    public new void TestMethod(bool b = false)
    {
        base.TestMethod(b);
    }
}

The proposed feature seems to add a lot of inconvenience for the programmer with no corresponding increase in representative power. What's the compelling benefit of this feature which justifies the increased cost to the user?

UPDATE: In the comments below, supercat suggests a language feature that would genuinely add power to the language and enable some scenarios similar to the one described in this question. FYI, that feature -- default implementations of methods in interfaces -- will be added to C# 8.


@supercat: We don't have any plans to do so, but a feature like that is possible. It's been proposed before. During the design process for C# 4 we kicked around a lot of what we called "extension everything" features -- we have extension methods, so what would it mean to have extension events, extension properties, extension constructors, extension interfaces, and so on. Classes that you could "attach" to interfaces and say "these methods are the default implementations of this interface" are one possible way to characterize "extension interfaces". An interesting idea.
to clarify my reasoning for why I think it is non-intuitive: to me an optional parameter is "optional to the caller of the method" NOT "optional to the implementer of the interface".
"Are they required in your world to call up the author of B on the phone and ask them to please ship them a new version[...]?" No, no phone calls required. B should simply no longer be able to be considered an implentation of MyInterface and the author of D could be made aware of that by the compiler. The author of D would be required to implement D with a TestMethod that accepts a default parameter since that is what the Interface author requires - you are arguing against allowing the interface author to enforce a constraint because someone might want to break it. That is not a good argument.
@EricLippert In the case where the optional parameter is being specified for coding convenience, yes, enforcing inconvenience in the implementation is counter-intuitive. But in the case where the optional parameter is being used to minimize method overloading, a powerful feature, those optional values may take on great significance and ignoring them certainly dilutes that power. Not to mention the case where the concrete implementation specifies a different default value than the interface. It just seems like a very odd disconnect to allow.
I agree with @philofinfinitejest here. An interface tells what something can do. If I am passed an implementation of an interface with a different default value than what the interface specifies, how am I to know that? Hey, I have an interface that passes true as a default, so why is this thing getting a false? That, would seem like I did NOT get the interface that I expected. Even worse, I now have to program to an implementation and not an interface.
C
CodesInChaos

An optional parameter is just tagged with an attribute. This attribute tells the compiler to insert the default value for that parameter at the call-site.

The call obj2.TestMethod(); is replaced by obj2.TestMethod(false); when the C# code gets compiled to IL, and not at JIT-time.

So in a way it's always the caller providing the default value with optional parameters. This also has consequences on binary versioning: If you change the default value but don't recompile the calling code it will continue to use the old default value.

On the other hand, this disconnect means you can't always use the concrete class and the interface interchangeably.

You already can't do that if the interface method was implemented explicitly.


Can you force implementers to implement explicitly though?
O
Olhovsky

Because default parameters are resolved at compile time, not runtime. So the default values does not belong to the object being called, but to the reference type that it is being called through.


A
Ariel Arjona

Optional parameters are kind of like a macro substitution from what I understand. They are not really optional from the method's point of view. An artifact of that is the behavior you see where you get different results if you cast to an interface.


H
Harshdeep Singh

Just want to add my take here, as the other answers do provide reasonable explanations, but not ones that fully satisfy me.

Optional parameters are syntactic sugar for compile-time injection of the default value at the call site. This doesn't have anything to do with interfaces/implementations, and it can be seen as purely a side-effect of methods with optional parameters. So, when you call the method,

public void TestMethod(bool value = false) { /*...*/ }

like SomeClass.TestMethod(), it is actually SomeClass.TestMethod(false). If you call this method on an interface, from static type-checking, the method signature has the optional parameter. If you call this method on a deriving class's instance that doesn't have the optional parameter, from static type-checking, the method signature does not have the optional parameter, and must be called with full arguments.

Due to how optional parameters are implemented, this is the natural design result.


r
robie2011

Thanks for your explanation @eric-lippert

Here is some code example:

[Fact]
public void TestOptionalMethodArgument()
{
    var implementation = new TestHello();
    IHello @interface = implementation;

    Assert.Equal(23, @interface.Action());
    Assert.Equal(40, implementation.Action());
}

public class TestHello : IHello
{
    public int Action(int number = 40)
        => number;
}

public interface IHello
{
    int Action(int number = 23);
}

J
Jim K
var obj = new MyClass();        
obj.TestMethod(); // compiler error

var obj2 = new MyClass() as MyInterface;
obj2.TestMethod(); // prints false

Use

MyInterface obj = new MyClass();        
obj.TestMethod(); // compiler error

var obj2 = new MyClass() as MyInterface;
obj2.TestMethod(); // prints false

and both result in false