What is the problem with implicit covariant inversion?

[zms9110750]

I hava this

public class Fight : ICloneable
{
	long hp;
	long atk;
	long def;

	public Fight Clone() => (Fight)MemberwiseClone();
	object ICloneable.Clone() => Clone();
}

Why do I have to take this?

object ICloneable.Clone() => Clone();

This interface only wants one object.
I gave him a Fight. Fight is a legal object.
Why doesn't he approve?

Similarly, if my parameters (no ref, out) can be implicitly converted to the type required by the interface, what's the problem?

[CyrusNajmabadi]

I don't really understand the question. All that code looks legal. What's the problem you're having with it?

[zms9110750]

I mean, I want him to be legal

public class Fight : ICloneable
{
	long hp;
	long atk;
	long def;

	public Fight Clone() => (Fight)MemberwiseClone();//I think this is an effective  "object ICloneable.Clone()"
}

[333fred]

We considered, but did not implement, automatic covariant return implementations of interface members. There's a potential for breaking changes where an interface member is reimplemented by a derived type unintentionally, so unlike overriding (which can indeed be covariant), implementation must be invariant and match exactly.

[zms9110750]

New knowledge. By the way, why does the parameter not allow covariant.
By unintentional, you mean that because of the type mismatch, the implementer cannot realize that the method he is rewriting is enough to have a impact on an interface?

[333fred]

why does the parameter not allow covariant

Did you mean contravariant? And because we haven't seen it be a particular problem that needs addressing 🙂.

the implementer cannot realize that the method he is rewriting is enough to have a impact on an interface

Not only that, but also it can cause current code, that does not implement an interface member today, to implement an interface member.

[zms9110750]

But I think, that if we use this way,
It seems to have the same problem.

public class Base : ICloneable
{
	public virtual Base Clone() => (Base)MemberwiseClone();
	object ICloneable.Clone() => Clone();
}
public class Child : Base
{
	public override Base Clone() => (Child)MemberwiseClone();
}

The implementer also does not know that this will modify the implementation of the interface.
The key to the problem seems to be that the base class implementer binds the method to the interface.
As long as the base class implementer does this, the derived class implementer cannot predict how.
Did I think less about anything?