Proposal: Covariance and Contravariance between T and Nullable(T)

[rvhuang]

As title says, let us see following three examples:

static void Example1()
{
    Action<int?> before = index => DoSomething(index);
    Action<int> after = before;
    // Cannot implicitly convert type 'System.Action<int?>' to 'System.Action<int>' 
}
    
static void Example2()
{
    Func<int, int> before = index => GetSomething(index);
    Func<int, int?> after = before;
    // Cannot implicitly convert type 'System.Func<int, int>' to 'System.Func<int, int?>' 
}

static void Example3()
{
    IEnumerable<int> before = Enumerable.Range(1, 15);
    IEnumerable<int?> after = before;
    // Cannot implicitly convert type 'System.Collections.Generic.IEnumerable<int>' 
    // to 'System.Collections.Generic.IEnumerable<int?>'.
}

Currently all three examples will cause compilation errors which basically share same issue. However, from a logical aspect, all implicit conversions in three examples seem feasible and do not violate current type system in C#. The Covariance and Contravariance between T and Nullable<T> in generic interfaces and delegates may be a thing.

[yaakov-h]

"may be a thing"?

[mikedn]

"may be a thing"?

Definitely not a thing.

The runtime doesn't support value type covariance and even if you somehow manage to convince the runtime team to try to do make it work (and that won't happen) there's still significant technical hurdles to get it to work.

Covariance works with reference types because converting between reference types is a no-op (except, of course, the type check that's required to maintain type safety in some cases). Converting between value types is not a no-op (except in some rather special circumstances), some piece of code somewhere needs to take an int and create an int? out of it.

[rvhuang]

some piece of code somewhere needs to take an int and create an int? out of it.

I see. So it seems implicit conversions like this eventually need help from API level. Maybe it can be done with "syntax sugar" in compile time but many details need to be figured out. Thanks for your reply.

[mikedn]

Maybe it can be done with "syntax sugar" in compile time but many details need to be figured out

The only thing that the C# compiler could do is creating a new object that "wraps" the existing object. Basically it could do the equivalent of code that you can write yourself:

Action<int> after = index => before(index);
Func<int, int?> after = index => before(index);
IEnumerable<int?> after = before.Select(i => (int?)i);

That's not a good idea because it turns something that looks like reference conversion into something that looks more like boxing/value conversion - reference identity is lost, objects are allocated, there are extra indirections etc.

[Logerfo]

What if Nullable<T> had an implicit conversion to T, instead of doing so as a compiler magic in certain cases, like pattern matching? There is some talk about that matter here: #1248

[mikedn]

What if Nullable had an implicit conversion to T, instead of doing so as a compiler magic

Implicit or not, any sort of conversion between value types is still "some piece of code somewhere".

[aluanhaddad]

With Non-nullable Reference Types, something like this will be badly needed.

[mikedn]

With Non-nullable Reference Types, something like this will be badly needed.

Why?!

[aluanhaddad]

@mikedn say you have an interface like

interface IMayHaveValue<out T>
{
    T? Value { get; }
}

and another interface

interface IHasValue<out T>: IMayHaveValue<T>
{
    new T Value { get; }
}

A variant relationship between would them enable you to write a method like

static IEnumerable<IHasValue<T>> HavingValues<T>(this IEnumerable<IMayHaveValue<T>> xs) =>...

In other words, with null taking the meaning optional it is massive usability pain that we cannot abstract over null checks or perform them at a distance.

Granted, this is my perspective after spending time with TypeScript a language where nullability is fundamental. But that language is structurally typed.

Currently I find the proposed C# feature neither ergonomic nor expressive.

EDIT: fixed example to make sense.

[mikedn]

say you have an interface like

Hmm, I'm not familiar enough with non-nullable references to tell if not having nullable value type covariance has any meaning in that context.

However, non-nullable references (and note how I keep omitting the word "type") are quite different from nullable value types. There are no actual nullable/non-nullable reference types, string and string? are the same type. So are IEnumerable<string> and IEnumerable<string?>. The runtime doesn't have a clue about string?, it's all string.

So, it's very unlikely that this issue has anything to do with non-nullable references.

[aluanhaddad]

@mikedn I see what you mean. Basically I was using the context as an excuse to complain