Irritation: Necessity of separate struct/class methods for dealing with nullable generics

[LyndonGingerich]

Disclaimer: I come from F# and thus may insufficiently understand the mindset of C#. I'll be humble.

Issue

Frequently, as I am writing a helper method involving generics and nullability, I find my code failing to compile because it needs a class or struct constraint on the generic type:

Version 1

public static T? GetFirst<T>(List<T> a) => a.Count > 0 ? a[0] : null; // Cannot convert expression type 'null' to return type 'T?'

I wish my method to work on either, so I copy and paste the method, then mark one for struct types and the other for class types:

Version 2

public static T? GetFirst<T>(List<T> a) where T : struct => a.Count > 0 ? a[0] : null;
public static T? GetFirst<T>(List<T> a) where T : class => a.Count > 0 ? a[0] : null;

But now I have a compiler error: "Member with the same signature is already declared". Since they cannot take the same types, I would have expected these two methods to be interpreted as overloads, but the compiler does not so evaluate them.

My usual workaround is to name them differently:

Version 3

public static T? GetFirstVal<T>(List<T> a) where T : struct => a.Count > 0 ? a[0] : null;
public static T? GetFirstRef<T>(List<T> a) where T : class => a.Count > 0 ? a[0] : null;

But this seems quite ugly.

Potential solutions

My usual workaround is to name them differently:

public static T? GetFirstVal<T>(List<T> a) where T : struct => a.Count > 0 ? a[0] : null;
public static T? GetFirstRef<T>(List<T> a) where T : class => a.Count > 0 ? a[0] : null;

But this is ugly.

Optimally C# would simply allow version 1, deducing that my method is valid for either struct or class types. But this seems too obvious. Since this behavior has not been implemented, surely it is impossible under the C# type system or something, correct?

What about version 2? T : struct and T : class are necessarily two different types. Could two methods so distinguished be made valid overloads?

[HaloFour]

These limitations are inherent to .NET, not C#.

Part of the confusion comes from the C# syntax for nullable reference types, T?. In that case the actual type is just T as it is already nullable. But for value types, T? actually refers to the special wrapper type Nullable<T>. It's not possible for the signature to vary based on the generic type argument, so without the struct constraint the T? type has to refer to T instead. As it's not possible for int or other value types to be null, the closest you can get is default or 0.

The second issue is that the runtime does not include generic type parameter constraints as part of the method signature. So it's not possible for two methods with identical signatures to differ only by generic type constraints. C# also does not permit methods to be overloaded based on return type, which might otherwise permit the overloading you are attempting since technically one method would return T and the other would return Nullable<T>.

One way you could resolve this is to return a wrapper type, something like Option<T>, instead of T?. That's probably how you'd solve such a problem with F# anyway.

[LyndonGingerich]

I'm assuming that none of that--particularly type parameter constraints included in method signatures--is subject to requests for change or enhancement?

[HaloFour]

You can always ask. Supporting generic type constraints in signatures has been requested before here:

It has been requested before: #2013

Eric Lippert posted a blog on this subject back in 2009, and while MSDN blogs are no longer online here's an archive of that blog post:

https://web.archive.org/web/20100922123630/http://blogs.msdn.com:80/b/ericlippert/archive/2009/12/10/constraints-are-not-part-of-the-signature.aspx

There have been some changes to the compiler since that was written, namely that C# will now remove overload candidates that violate the generic constraints. There is still the issue of overloads and signatures, although that is more of a C# limitation as it does not permit overloading based only on return type in the method signature. The runtime does allow this.

[LyndonGingerich]

@HaloFour Many thanks!

[KennethHoff]

@HaloFour does this mean that there is so longer a technical limitation for overload-by-constraint, but rather a language/"not yet taken the time to implement it" kind of limitation?

[HaloFour]

does this mean that there is so longer a technical limitation for overload-by-constraint, but rather a language/"not yet taken the time to implement it" kind of limitation?

For this specific case yes, but that's only because T? for a reference type is really T whereas T? for a value type is really Nullable<T>, so as far as the CLR is concerned the return types would be different between the two signatures. That's also why the following is already legal today:

public void M<T>(T? x) where T : class { }
public void M<T>(T? x) where T : struct { }