[Still not an optimal experience] C# 9.0 provides generics that supports both nullable classes and structs, but it only does it 50%

[jannickj]

Example assume I want to provide a nullable wrapper for dictionary's TryGetValue

public static class DictionaryExt
{

	public static TVal? TryGet<TKey, TVal>(this Dictionary<TKey, TVal> dic, TKey key)
		where TKey : notnull
	{
		if (dic.TryGetValue(key, out var val))
		{
			return val;
		}
		return null;
	}

this gives you Cannot convert null to type parameter 'TVal' because it could be a non-nullable value type. Consider using 'default(TVal)' instead.
Now this is terrible advice if you actually do this i.e. null -> default then

var dict = new Dictionary<int, int>();
var val = dict.TryGet(0);
> val.GetType() == typeof(int) && val == 0
true

instead what you actually have to do (like you did in c# 8.0)

public static class DictionaryExtStruct
{
	public static TVal? TryGet<TKey, TVal>(this Dictionary<TKey, TVal> dic, TKey key)
		where TKey : notnull
		where TVal : struct
	{
		if (dic.TryGetValue(key, out var val))
		{
			return val;
		}
		return null;
	}
}

public static class DictionaryExtClass
{
	public static TVal? TryGet<TKey, TVal>(this Dictionary<TKey, TVal> dic, TKey key)
		where TKey : notnull
		where TVal : class
	{
		if (dic.TryGetValue(key, out var val))
		{
			return val;
		}
		return null;
	}
}

All of it coming from the fact that null is not valid return type from something that returns [type]? which is obviously incorrect.

[Joe4evr]

This is intentional. You can't change a struct substitution to a Nullable<T> from an unconstrained generic parameter without CLR changes.

[jannickj]

What would you expect? T is unconstrained so it can't really be Nullable<T>.

T can't be Nullable<T> but T? could easily be Nullable<T> The whole point of a type function (generics) is that the compiler can resolve the actual types as it pleases. If I write int? the compiler will happily resolve it as Nullable<int>. So I don't see why it can't be the same for generics (other than legacy).

It's only from caller's point of view that it might locally inferred as int which is actually the value default(int),
that's why it's called FirstOrDefault not FirstOrNull.

FirstOrDefault is probably also the biggest antipattern function in the language, the first thing I do to any code base is create a FirstOrNull function. If Null exceptions is a billion dollar mistake, then I don't want to think about the dollar size of silent struct defaulting.

[alrz]

So I don't see why it can't be the same for generics

Nullable<T> is constrained to structs only, that's why. Though it might be possible to use some kind of Option<T> type that works for unconstrained types but without runtime support it will suffer from an additional unnecessary boolean flag being carried around for reference types.

You may argue that we could postpone this feature until we have a runtime solution and I'd totally agree with that.

[jannickj]

Nullable<T> is constrained to structs only, that's why. Though it might be possible to use some kind of Option<T> type that works for unconstrained types but without runtime support it will suffer from an additional unnecessary boolean flag being carried around for reference types.

No my point is that if T is struct then T? -> Nullable<T> and if T is class then T? -> T just like if I write typeof(int?) == typeof(Nullable<int>) and typeof(object?) == typeof(object)

[HaloFour]

The compiler doesn't resolve generics, the runtime does, and the runtime both doesn't understand NRTs nor does it support replacing the generic type in that manner. There's not much the compiler can do here without runtime support, short of trying to emit two completely separate members.

[jannickj]

The compiler doesn't resolve generics, the runtime does, and the runtime both doesn't understand NRTs nor does it support replacing the generic type in that manner. There's not much the compiler can do here without runtime support, short of trying to emit two completely separate members.

Fair enough I didn't actually know that 😅, guess I learned something new today :)