Proposal: Support covariant generic classes and structs

[PhilipCavanagh]

With C# moving towards a more functional approach, I'm finding myself using monad types more frequently. Types like Task<T>, Lazy<T>, Option<T>, Maybe<T>, etc. would benefit from being allowed to be covariant in their generic types. They are also frequently the sort of types that would benefit from being structs, which means that having them implement a covariant interface loses much of their benefit.

This proposal would alleviate a particular pain in would-be covariant types which contain an async method:

public interface IAsyncValueGenerator<T>
{
    Task<T> GenerateValueAsync();
}

If Task<T> could be made covariant, then so could the interface.

Specifically, a class or struct can be declared as covariant in its generic parameter only if that parameter type only appears in out positions. A simple test for this is to strip out all access modifiers, implementations, fields and constructors and changing the class or struct to an interface. If the interface could be made covariant, then so can the original class/struct.

[HaloFour]

The limitation of variance only being applicable to interfaces and delegates is imposed by the CLR. You can force an assembly to compile with a variant generic class using IL but the result will not be verifiable.

I wonder if custom async builders would allow for a variant Task<T> analog.

[TahirAhmadov]

Have there been any updates about lifting this limitation?

[mburbea]

Variance on a struct, I don't think makes sense, as the assignment would be copying. But on a class sure that's reasonable.
See #171, and the fact that it was closed. I 100% agree, and I would love this.

Although now that there is support for async pattern matching, you can change that interface to use something like ITask<T>.

[PhilipCavanagh]

That's a good point about the struct I hadn't considered. It's no less efficient to implement an extension method which creates a new instance than this proposal would be.

I had done a search for a similar proposal to this one, but I missed #171. This can probably be closed too in that case.

[PhilipCavanagh]

That said, an assignment of a generic reference type whose type parameter is a generic struct (e.g. IReadOnlyList<Option<string>>) would only require a copy of the reference - the structs would stay where they are, inside the IReadOnlyList<T> instance. Assigning that instance to a IReadOnlyList<Option<object>> variable would mean copying the list reference, and would require the actual bits of each Option<string> to be treated as those of an Option<object>. As far as I can tell, there's no reason this is impossible.

As it is, to get hold of an IReadOnlyList<Option<object>>, you'd have to create an entirely new list full of new Option<object> instances, each constructed from the strings in the original list.

[Frassle]

Variance on a struct might still make sense from a type-safety point of view. Take ImmutableArray structs, you should be able to assign an ImmutableArray<string> to ImmutableArray<object>, the fact that the backing array is still a string[] isn't a problem all the bits are the same and this would be type safe.

[egil]

Would this not be relevant for readonly struct as well?

[PCavan]

It would - a struct being readonly would automatically qualify it for covariance on each of its type arguments.

[Joe4evr]

@PCavan I'd say such types should still explicitly declare to be variant, just to avoid (potential) strange behavior changes, but that's about the only nit I see with that.

[PCavan]

@Joe4evr I can't think of an example where automatically adding covariance to readonly structs would change behaviour (which is not to say there isn't one).

Given that readonly structs aren't covariant now, any compiling code must be using the exact same compile-time type argument as the struct instantiation, and because that option is guaranteed to be available now, the compiler would continue to choose that option even if the struct were covariant as the exact match is always the best match.

public readonly struct Option<T> { ... }

public interface IOptionalAcceptor
{
    void Accept(Option<string> x);
    void Accept(Option<object> x);
    void Accept(Option<IComparable> x);
}

...

Option<string> x = Option.From("Hello world");
IOptionalAcceptor a = ...;

// This will choose Accept(Option<string>).
// Removing Accept(Option<string>>) will fail to compile with or without auto-covariant readonly structs (ambiguous method call vs no valid method).
a.Accept(x); 

On the other hand, preferring explicitness on these things seems to be C#'s way of doing things (e.g. having to use out, ref at call sites), so maybe it ought to be opt-in.

[yaakov-h]

IIRC, automatically adding covariance would break readonly structs that have mutable storage from another object, e.g.:

using System.Collections.Generic;

public readonly struct Listy<T> {
    
    public Listy(List<T> list) => this.list = list;
    
    readonly List<T> list;
    
    public T Get(int i) => list[i];
    public void Add(T t) => list.Add(t);
}

[Richiban]

If that struct was covariant over T wouldn't the public void Add(T t) => list.Add(t); be disallowed? T is used in an input position there

[andre-ss6]

If that struct was covariant over T wouldn't the public void Add(T t) => list.Add(t); be disallowed? T is used in an input position there

@Richiban exactly. @yaakov-h 's point was to provide an example of a scenario where automatically adding covariance to readonly structs would fail.

[nu-i-sho]

What is the problem with following the same as for interfaces?

public readonly struct InvariantListy<T> {
    
    public Listy(List<T> list) => this.list = list;
    
    readonly List<T> list;
    
    public T Get(int i) => list[i];
    public void Add(T t) => list.Add(t);
}

public readonly struct CovariantListy<out T> {
    
    public Listy() => this.list = new List<T>();
    
    readonly List<T> list;
    
    public T Get(int i) => list[i];
}

public readonly struct ContravariantListy<in T> {
    
    public Listy(List<T> list) => this.list = list;
    
    readonly List<T> list;
    
    public void Add(T t) => list.Add(t);
}

[PCavan]

@yaakov-h Ah, good point. I was surprised that was legal C# code when I read it, but this is another case of "Read-only does not mean immutable".

In fact, thinking about it, even immutability isn't enough to guarantee covariance - public T Identity(T t) => t; is valid on any struct or class, and is invariant in T.

Even if the covariance change had to be explicit, at least I think what I said above holds in that making the change won't break anything code that uses the struct (the same can't be said for covariant classes - there's no guarantee it's using the exact same type already).

[ufcpp]

Could structs be covariant if all of its fields are covariant?

[TahirAhmadov]

This may be a good idea, if the fields are all readonly. I would suggest you open a discussion about it - it's worth looking into it a little.

[andre-ss6]

This would marry well with records (#89) I think. Immutability comes for free, which makes it that easier to implement covariant classes.

And it's currently a pain to deal with this limitation when you want to use generic variance on "data" classes (without behavior/logic), as you have to use interfaces, and the code starts looking quite insane when you have interfaces all over for just passing data around.

[andre-ss6]

In fact, thinking about it, even immutability isn't enough to guarantee covariance - public T Identity(T t) => t; is valid on any struct or class, and is invariant in T.

I'm not sure if I understood it right, but wouldn't a class of T covariant on T be forbidden from having a method takes a parameter of type T?

[PCavan]

@andre-ss6 Yes it would, but I was considering whether immutability implies generic covariance. The Identity method above would be valid on an immutable struct, but would exclude the struct from covariance on T.

[jam40jeff]

I wonder if custom async builders would allow for a variant Task<T> analog.

https://github.com/jam40jeff/ITask

[andre-ss6]

I wonder if custom async builders would allow for a variant Task<T> analog.

https://github.com/jam40jeff/ITask

The issue with using custom awaitables is that there are some compiler and/or JIT optimizations that apply only to the known types Task and ValueTask.

[pedrocpneto]

Since record types are immutable, it should be covariant as an IEnumerable interface, for example, given the following type:

record Envelope<TData>(TData Data);

It should be possible to use like this:

var recordS = new Envelope<string>("Hello World");
Console.WriteLine(recordS.Data);

var recordI = new Envelope<int>(5);
Console.WriteLine(recordI.Data);

Envelope<object> record = recordS;
Console.WriteLine(record.Data);

record = recordI
Console.WriteLine(record.Data); 

[HaloFour]

Even if classes could be variant, that doesn't apply to value types as they require completely different storage. That's why it's illegal to cast from IEnumerable<int> to IEnumerable<object> today.

[Joe4evr]

Since record types are immutable

That's not strictly true: It's perfectly fine to declare a record type with mutable properties, and that's a perfectly fine supported scenario.

[MatisseHack]

Covariant generic classes would be particularly useful for Task<T>. I've always wished I could write this generic extension method:

public static async IAsyncEnumerable<T> ToAsyncEnumerable<T>(this Task<IEnumerable<T>> task)
{
    foreach (var item in await task)
    {
        yield return item;
    }
}

Task.FromResult(new List<object>()).ToAsyncEnumerable() // Cannot implicitly convert type... 😞

[aradalvand]

Makes no sense that this isn't already supported.