Proposal: Allow unconstrained generic type parameters to be nullable references

[bkoelman]

I propose to no longer issue CS0453 on methods with the next signature in the features/NullableReferenceTypes branch:

public static void M3<T>(T? arg) { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

but instead, consider the signature equivalent to:

public static void M3<T>([Nullable] T arg) { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

where [Nullable] refers to the inaccessible compiler-builtin annotation for a nullable reference type.

I believe this will not break existing code, as the construct is currently not allowed:

        // CS6 + Prototype: allowed
        public static void M1<T>(T arg) { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

        // CS6 + Prototype: allowed
        public static void M2<T>(T? arg) where T : struct { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

        // CS6 + Prototype: allowed
        public static void M3<T>(T arg) where T : class { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

        // CS6 + Prototype: CS0453
        public static void M4<T>(T? arg) { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

Applying this proposal would enable callers to pass in value types (which get boxed), nullable value types (get boxed), never-null reference types and nullable reference types.

To clarify: In this proposal, the unconstrained generic type T? is interpreted as [Nullable] T, not Nullable<T>.

This proposal aims to not:

• Require changes to overload resolution (attributes are not taken into account)
• Require CLR changes (this is not about unification of types)
• Require changes in value type boxing (that already happens)

From what I understand, this seems very straightforward. Without asking for alternative proposals (or potential theoretical scenarios), are there any reasons that make doing this impossible?

I am aware this proposal makes it impossible to have these two overloads:

        public static void M<T>(T? arg) { } // => public static void M<T>([Nullable] T arg) { }
        public static void M<T>(T arg) { }

as their signatures (from a CLR perspective) are not overloads. That does not bother me, though.

I would appreciate to center the discussion around the current prototype, not other directions it may or may not take in the future. Therefore, I'd kindly ask you to verify your assumptions against the actual prototype before responding. This prevents the discussion steering somewhere else, based on (incorrect) assumptions.

[bkoelman]

CC @MadsTorgersen @AlekseyTs

[HaloFour]

So the net result of this proposal is the following:

public void M<T>(T? value) { }

M<int>(5); // good
M<int?>(null); // good
M<string>(null); // good
M<int>(null); // CS1503: cannot convert from '<null>' to 'int'
M<int>(default(int?)); //CS1503: cannot from 'int?' to 'int'

That may be confusing.

Is it really necessary to have this proposal be separate from #9932 ?

[alrz]

@bkoelman

public static void M<T>([Nullable] T arg) { }

How this is supposed to work?

M<int>(null); 

[alrz]

I'll also note that

public static void M3<T>([Nullable] T arg) { Console.WriteLine(arg == null ? "null" : arg.ToString()); }

This is already a compile-time error. How possibly this proposal aims to _NOT_ require CLR changes?

[bkoelman]

Did you verify that it's a compile error?

[alrz]

@bkoelman arg can never be null if T is a value type. I think that is the point.

[alrz]

@bkoelman If you are talking about M3<int?>(null) then I have no idea how M3<T>(T arg, T? arg2) would work.

[HaloFour]

My preference would be that if you wanted to abuse the new attributes then you should do so explicitly and that the ? suffix shouldn't blindly mean to apply said attribute in cases when the type isn't a reference type. Even if nullable equivalence is not possible in the C# 8.0 time frame (or whenever this might ship) I'd rather leave that syntax open to better future enhancement.

[bkoelman]

@HaloFour

So the net result of this proposal is the following:

Correct

@alrz

How this is supposed to work?

Not, compile error.

arg can never be null if T is a value type. I think that is the point.

Correct, and I would not expect otherwise. How strange would it be when you pass in a int that become null, right?

M3(T arg, T? arg2)

T is a not-nullable reference type, T? is a nullable reference type.

I get that T? in this case means "reference type only". That's because T is unconstrained. You may not like that, but that is actually what I am proposing.

@HaloFour

My preference would be that...

I'm not abusing anything. Just trying to convert code that works today (with Resharpers CanBeNullAttribute) and seeing where that gets me. Well, here I'm stuck. I have no objection against exposing the NullableAttribute as a normal type. In the current prototype it's inaccessible, though.

[alrz]

@bkoelman

T is a not-nullable reference type, T? is a nullable reference type.

No, T is not a reference type, it is just a generic type.

Actually the title doesn't make sense to me, "Allow unconstrained generic type parameters to be nullable references" an unconstrained generic type is not a value type nor a reference type.

[bkoelman]

@alrz That is the key point of my proposal.

Today, for an unconstrained T parameter, you can pass in int, int? and string. That's stays as-is.

For an unconstrained T? parameter, you get a compile error today. I propose to change that to: consider T? a nullable reference type, which allows you to pass in int (auto-boxed), int? (auto-boxed), string and string?.

Obviously, when adding where T : struct or where T : class this rule no longer applies.

That's all.

[HaloFour]

@alrz Oops, updated comment.

@bkoelman I haven't toyed with the branch yet, but how is the attribute inaccessible? The type would need to be public and have a public constructor if the compiler were going to apply it, so I don't know how you wouldn't then be able to apply it manually unless the compiler was explicitly forbidding you from using that attribute manually. This is what the compiler does with System.Runtime.CompilerServices.ExtensionAttribute so that's not without precedent. And if the compiler were to be strictly preventing you from using the attribute manually in arbitrary/inappropriate cases then I would think that the compiler should also prevent you from using it where it doesn't make sense, like an unconstrained generic type.

[bkoelman]

@HaloFour I'm not sure why. Maybe you can fetch the branch and give it a try?

[HaloFour]

@bkoelman

For an unconstrained T? parameter, you get a compile error today. I propose to change that to: consider type parameter T a nullable reference type, which allows you to pass in int? (auto-boxed), string and string?.

So, wait, you're proposing that it be possible that M<T>(T? value) be able to accept an int? when T is int?

[alrz]

That was also my question when I said I don't know how M3<T>(T arg, T? arg2) would work (for int).