T? with constraint T : class?

[Jeremy-Price]

It seems that this constraint is disallowed. But that doesn't seem right. Consider the example:

class A<T> where T : class?
{
   T F1(); 
   T? F2();
}

A<string>.F1 cannot return null
A<string>.F2 can return null
A<string?>.F1 can return null
A<string?>.F2 can return null

A's contract basically says, "I can deal with null T's if you want. F1 will only return null if we're dealing with null T's, but F2 may return a null even if we're not dealing with null T's, e.g. it can be a lookup that can fail."

But this seems to be an error for F2:

error CS8627: A nullable type parameter must be known to be a value type or non-nullable reference type. Consider adding a 'class', 'struct', or type constraint.

https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQxASwDZICYgNQA+AAgAwAERAjANwCwAUAwMQB2ArhhhMBnGXC268GRAExkAggB4AKgD4yAdwAWiPjLIgKogPxIyLOIoAUASgYBvBmRsaAYpTNkAvAsOKyMs3Xo3POsjtRJ1cDDgwfAF8GBiA===

[john-h-k]

if you are saying T : class?, then surely T? is T???? - the point is, you just have T : class and then return nullable where applicable

[YairHalberstadt]

FirstOrDefault is an example of a method which would have such a signature. I think the plan is to use attributes to sort out cases like this.

[Jeremy-Price]

FirstOrDefault is an example of a method which would have such a signature. I think the plan is to use attributes to sort out cases like this.

I'm not clear on how the proposed attributes are supposed to solve this. It was my understanding that they were for annotating that a method like TryGet would return true iff the out parameter is non-null. But that doesn't help the example above...

Changing the constraint on A from class? to class changes the contract for A, because T values that A handles may no longer be null.

This is important when, e.g., calling a generic method from another generic method.

void Foo<T>() where T : class?
{
    A<T> a = new A<T>(); // can't do this now if A's constraint was changed to "class".
}