Why doesn't covariance work in this case?

[fandrei]

This code works.

abstract class TreeNodeBase
{
	public virtual TreeNodeBase Parent { get; }
	public virtual IReadOnlyList<TreeNodeBase> Children { get; }
}

class TreeNode : TreeNodeBase
{
	public override TreeNode Parent { get; }
	public override IReadOnlyList<TreeNode> Children { get; }
}

This code doesn't compile.

interface ITreeNode
{
	ITreeNode Parent { get; }
	IReadOnlyList<ITreeNode> Children { get; }
}

class TreeNodeInt : ITreeNode
{
	public TreeNodeInt Parent { get; }
	public IReadOnlyList<TreeNodeInt> Children { get; }
}

Why doesn't it work in the second case?

[TahirAhmadov]

The override rules are different than interface implementation rules.

#296

[fandrei]

@TahirAhmadov what's motivation for this difference? Logically, the relationship between the types is same in both cases.

[TahirAhmadov]

There are some subtle differences. I don't recall the details right now, but there were some discussions on the subject in other threads.

However, it doesn't mean your proposal (and #296) can't work.

I do remember somebody (maybe @HaloFour) stating that the way to achieve this would be silently emitting a bridge method, because at the IL level, making variant method implement the interface method is difficult for some reason.

[fandrei]

@TahirAhmadov do you remember where those discussions were? Any key words?

[TahirAhmadov]

I found #296 by searching for "interface implementation variance" or something similar. I'm pretty sure there were other discussions on this topic, as well, but I couldn't find them (in the admittedly short amount of time I looked) and I definitely don't remember them. Sorry I couldn't help more.

[CyrusNajmabadi]

One is an override (where variance is supported). One is an implementation, where it is not. If you wanted it supported, it would need a proposal and specification for how it worked (either with runtime support, or a stub method emitted).

[CyrusNajmabadi]

@dnfadmin please stay on topic. There's no evidence that success for any of these groups has come from any sort of adherence to the philosophy you are espousing.

As has already been mentioned, we add things to the language we think provide substantial value to the ecosystem. If you think this should be fine, make a case. We'll consider it against the several other thousands of things that others are asking for as well. If this beats that stuff out, it will be done.

[CyrusNajmabadi]

@fandrei this is an open source project with heavy community involvement. We've outlined how things are handled here. Thanks.

[fandrei]

@CyrusNajmabadi sure. As a developer of this project, do you remember where previous discussions of this topic were?

[CyrusNajmabadi]

Off the top of my head, I do not. Covariant returns were several years back, and took runtime support. So it would be around then.

[RikkiGibson]

One workaround here would be to explicitly implement the interface member, then declare an additional member which is "the same, but covariant". This is essentially manually implementing the "stub method" which was suggested in #8541 (reply in thread).

interface ITreeNode
{
	ITreeNode Parent { get; }
	IReadOnlyList<ITreeNode> Children { get; }
}

class TreeNodeInt : ITreeNode
{
	ITreeNode ITreeNode.Parent => Parent;
	public TreeNodeInt Parent { get; }

	IReadOnlyList<ITreeNode> ITreeNode.Children => Children;
	public IReadOnlyList<TreeNodeInt> Children { get; }
}

[colejohnson66]

This is the same pattern used by IEnumerable implementations:

public class MyClass : IEnumerable<SomeType>
{
    IEnumerator IEnumerable.GetEnumerator() =>
        GetEnumerator();
    public IEnumerator<SomeType> GetEnumerator()
    {
        // ...
    }
}

Give people the generic enumerator, but for users holding onto a non-generic IEnumerable, just forward the call.

[fandrei]

Looks like this feature was already discussed in #49 and added to the proposal, but the part about covariance in interfaces was not implemented. The reason is unclear.

[fandrei]

@HaloFour in this case, it's very far from "tons of additional effort".
By the way, Fred Brooks was as pragmatic as it gets. And not creating problems for your future self is very pragmatic.

[HaloFour]

in this case, it's very far from "tons of additional effort".

It is tons of effort, especially since the runtime doesn't support it.

And not creating problems for your future self is very pragmatic.

What problems? Aside some philosophical noise I don't see any problems blocked by a lack of this specific solution. Explicit interface implementation already enables you to support a covariant implementation, always has.

[fandrei]

@HaloFour auto-generation of stub methods would be perfectly enough.

You can say pretty much same thing about most new features discussed here. It's nearly always possible to solve the problem writing more boilerplate code rather than changing language. It's all the matter of convenience.

[HaloFour]

auto-generation of stub methods would be perfectly enough.

That would make it inconsistent, thus bring about the downfall of C#.

You can say pretty much same thing about most new features discussed here. It's nearly always possible to solve the problem writing more boilerplate code rather than changing language. It's all the matter of convenience.

Sure, but it's a question of ROI. If enough benefit is demonstrated that it's worth the massive effort (which is the bare minimum amount of effort), then yes, syntax candy will be added to the language. But, to paraphrase poorly, too much syntax candy leads to syntax cavities. Not to mention, there enough enough proposals on the backlog on this repo to represent decades of work, many of them easily worth more than this.

[fandrei]

@HaloFour what inconsistency you mean?
And many of them are worth much less than this one, including those that were implemented.