Question about notnull generic constraint

[dsaf]

https://devblogs.microsoft.com/dotnet/try-out-nullable-reference-types

It is quite common to intend that a generic type is specifically not allowed to be nullable.

If I prefer to avoid null-s in most cases and do <Nullable>enable</Nullable> as well, will I still need to decorate all of my generics with notnull constraints rather than occasionally opting out via e.g. null constraint?

[DavidArno]

I'd second this. I've recently added <Nullable>enable</Nullable> to a project and then had to add where T : notnull on a large number of classes. This seems completely back to front to me too. If I've enabled NRT's, then I'd expect where T : notnull to be the default and to have to add where T : nullable in those instances where I'd want to use T?.

Sadly I suspect there isn't time to "fix" this before v8 ships and once shipped, it would become a breaking change to invert it. So we are likely stuck with this.

[YairHalberstadt]

A lot of generic code without any constraints is type oblivious. The classic cases such as collections, Linq etc. all work on any type, including null.

So I think this is the correct default for nullable code.

[DavidArno]

The default state for nullable/not nullable once NRTs is enabled is not nullable. And to enable the former, one just needs ?. Yet the default state for generics is nullable and to switch to not nullable, where T : notnull is needed. There is therefore an inconsistency and the need to add very verbose code to maintain not nullable in generic code.

I've just worked through a library of only a few thousand lines of code that uses a lot of generics. Having made the decision in one place that the generic type must not be nullable, I then had to add around 300 where T : notnull to the code as it's another "zombie virus" akin to async. Adding it to one type, means all types that use that type then need the same constraint. All to achieve what is the default for non-generic types.

So to my mind, the team got this one completely wrong.

[alrz]

I'm thinking that the premise is that the generic code usually doesn't care about the type (e.g. Linq) -- nullable-in, nullable-out, and vice versa. so they need to be explicitly "constrained" to be not null.

I haven't palyed with NRT that much yet, @DavidArno could you give a example where notnull is actually helpful to you?

[DavidArno]

@alrz,

The simplest example I can come up with is this one:

#nullable enable

class C1<T>
{
    public string M1(T x) => x.ToString();
}

I can add a ! (public string M1(T x) => x!.ToString();) to suppress the warning, but then I risk a runtime error. So I add where T : notnull and the compiler is happy, for that one class. But if I eg add another generic class that has a C1<T> field:

#nullable enable

class C1<T> where T : notnull
{
    public string M1(T x) => x.ToString();
}

class C2<T>
{
    private C1<T> _x;
}

then the compiler insists I add that where T : notnull to C2 too and so it goes on. Before you know it, just needing that one constraint spreads the need for the same constraint in many many places in the code. All because of the "premise ... that the generic code usually doesn't care about the type".

[alrz]

Before you know it, just needing that one constraint spreads the need for the same constraint in many many places

Yeah, if it was in reverse e.g. : null I think that would not be required because a nullable T can still accept a non-nullable T. I'm torn on this, maybe someone from the team could better justify the decision.

[YairHalberstadt]

Adding it to one type, means all types that use that type then need the same constraint. All to achieve what is the default for non-generic types.

That is true of any constraint on generics. By default, a generic allows all types. Constraints restrict that, and are inherently viral.

The question isn't "is this constraint viral?". It's "which is more common, to have this constraint or not to".

Also I would point out it would be unique to have a where nullable constraint which increases the usages of the generic rather than decreasing it, so you would need an extremely strong case for this. where ref struct would be another example where this might be desirable.

[alrz]

@DavidArno Though I'm yet to see a real-world example of this, I hardly recall calling ToString on an unconstrained generic type. Note that if you have another type constraint it is actually non-null by default.

class C
{
    public string M1<T>(T x) where T : C => x.ToString();
}

[DavidArno]

@alrz, in realty, my use cases are around using GetHashCode and Equals or unconstrained generic types. But I can work around those with x is {} y ? y : 0 and x is {} y ? y.Equals(z) : z is null respectively.

So I'm now trying to remove all those where T : notnull constraints and may well end up eating my own words and deciding the team got it right after all. Don't tell anyone though 😉

[quinmars]

@DavidArno, another way would be to use EqualityComparer<T>.Default. It can handle nulls and omits boxing of values (if implementing IEquatable).