Assigning null to T? if typeparameter T is unconstrained

[PaulRitter]

Excuse me if this has already been asked before, i searched through the discussions & issues and didn't find this question.

I've been working with generics paired with nullability and one pitfall i've ran into again and again is the following:
These methods are fine:

T? ReturnVal<T>() where T : class => null;

T? ReturnVal<T>() where T : struct => null;

While this one produces an error, claiming "Cannot convert null to type parameter 'T' because it could be a non-nullable value type"

T? ReturnVal<T>() => null;

Now we are obviously trying to return T? here, not T. However, for this, we have an explanation:

Reading through the spec, it seems that T? is not allowed for unconstrained type parameters.

csharplang/proposals/csharp-8.0/nullable-reference-types-specification.md

Line 163 in 65580d8

For a type parameter `T`, `T?` is only allowed if `T` is known to be a value type or known to be a reference type.

As far as i can tell, this causes T? in our case to be implicitly converted to T. Additionally, this causes substituting null with default(T?) to return default(T) instead of null, meaning the method will not return null values when called with a struct as type parameter.

Now my question, at the risk of sounding a bit stupid, is: Why? As far as i can tell, there isn't really any type i could pass as a type parameter that could not be made nullable, so why impose this restriction? Is this due to internal limits since struct-null-values are actually the default of Nullable, not genuine null-pointers?

Genuinely curious what could be the cause of this, thanks in advance :)
- Paul

[bernd5]

@PaulRitter the problem is that not the JITTer implements nullability - it is done by the IL Compiler.

For example: T? ReturnVal<T>() where T : struct => null;
is compiled to:

static Nullable<T> ReturnVal<T>() where T : struct
{
        return null;
}

while T? ReturnVal<T>() where T : class => null;
is compiled to:

static T ReturnVal<T>() where T : class
{
        return null;
}

[PaulRitter]

Makes sense, i figured as much. Thanks for the quick response!
Although this begs the question if there may/should be some way to handle this issue, since on the developer-facing side, if you ignore the constraints imposed by the nullability implementation, it should be possible.

For now tho, i'll just continue to specialcase value- & referencetypes :/

[Joe4evr]

This has been asked about many times before and the simple answer is that it's not possible to combine the two scenarios, as there is no way to emit IL that is both T for reference types and Nullable<T> for value types for the same symbol.

[TahirAhmadov]

Please look at this: #4080
There is a way to make it work, but unfortunately it seems the language went in the direction of sweeping this under the rug.

[HaloFour]

With something like Null<T> you have two unsavory choices:

1. Break the existing ecosystem by updating libraries so that they pass Null<T>.
2. Have to build a second shadow ecosystem where those libraries are correctly updated to use Null<T>, but all of the existing libraries are still around with their T that allow null.

Either way you end up with a schism that will undoubtedly take decades to resolve, if ever.

[TahirAhmadov]

@HaloFour I thought about that. I think for LINQ, new methods can be created; existing ones would have been decorated with NRT attributes to achieve a similar effect. In other cases, however, the unconstrained T? is a brand new feature - there would be nothing to update, it's all new development. And if a new library returns Null<T>, and an existing one expect T?, and T is class, then my proposal accounts for it - it would be auto-converted ("unwrapped"), as needed, and vice-versa. I think people are over-exaggerating the potential problems with it.

[CyrusNajmabadi]

? nd if a new library returns Null, and an existing one expect T?, and T is class, then my proposal accounts for it - it would be auto-converted ("unwrapped"),

There is no way to do this unwrapping at the callsite. recall that the consumption code might be on prior versions of .net or C#.

I think people are over-exaggerating the potential problems with it.

Literally one of the first things i might ever write (statically cached data) is not binary compatible. I would hit that in one minute of trying to use this. That's a serious and significant problem.

In other cases, however, the unconstrained T? is a brand new feature

No, it really wouldn't be. And that's a core problem with this perspective here. By using T? you are dropping into the NRT world, and behaving in a way that is now incompatible with the ideas that we firmly imbued into that world woudl be a serious problem. Rember that a prime reason we even did anything in this space was because of the high feedback and problems people were having annotating real generic code to be NRT safe. That was much more of an issue than people in your position wanting a uniform representatin of null over value-types and reference-types.

You are asking us to use the same syntax to solve a different problem, and at hte same cause a schism with the group that very much needed help using this syntax to improve the NRT+generics scenario. I get you think your use case was more important, and you should have gotten first dips on ?. We disagree. I'm not sure what else can be said about that.

If you want your use case to be reconsidered, that's totally fine. Create a reasonable proposal with reasonable syntax that works well with the current form of C# and doesn't clash with it. If you do, there's a potential future for it. But lamenting that we decided to take a piece of syntax to mean something that we think is the superior interpretation for the ecosystem isn't going to go anywhere. We're certainly not going to change the meaning of it, and we still think it was the right choice given all the constraints we're operating under.

[sab39]

I know that in concrete terms the question is moot, and maybe that means that even considering the hypothetical is unproductive, but I feel like it might help with reconciling the conflicting views here: @CyrusNajmabadi, would you agree that if we could go back to 2005 (or 2004 or whenever the implementation of C#2 started), and design from scratch without Nullable<T> existing yet, then knowing everything we know now about this topic,

• it would be a no-brainer to want to design nullable value types in a way such that this wouldn't be impossible later, and
• that if it weren't impossible, it would be a no-brainer for NRT to to be designed such that unconstrained T? would mean that null was allowable for both value and reference types?

[CyrusNajmabadi]

If we were doing it all over again, we'd have a complete story for if null even exists and what that concept (or anything related to it) would mean for all of .net.

ALl this stems from allowing null to exist in the first place, and then trying to reconcile very disparate worlds in .net and what it means in all of that.