Variable is treated as "not null" where it's supposed to be "may be null"

[MrTA2]

Consider the following code:

//CocFile? cocFile = await dbContext.CocFile.FirstOrDefaultAsync(x => x.Id == id);
CocFile? cocFile = dbContext.CocFile.FirstOrDefault(x => x.Id == id);
if (cocFile.UpdateDT != updateDT) { ........ }

The cocFile variable is treated as not null, which introduces the possibility of bugs, because FirstOrDefault (and its async counterpart) can return null. Is it because those methods aren't decorated with attributes?

public static class Test
{
	// this works I think
	[return: MaybeNull]
	public static T FirstOrDefault2<T>(this IEnumerable<T> This)
	{
		return default;
	}
	// this works, almost - because:
	[return: MaybeNull]
	public static async Task<T> FirstOrDefaultAsync2<T>(this IEnumerable<T> This)
	{
		return default; // this gives CS8603 "Possible null reference return"
	}
}

The other option is to make 2 versions of these methods, one where T is class and one where T is struct, then return type can be T?, which means 2 different things (attribute-decorated reference T and Nullable, respectively). This is a non-starter for Enumerable and Queryable classes for obvious reasons (or is it??)

public static async Task<T?> FirstOrDefaultAsyncClass<T>(this IEnumerable<T> This) where T : class
{
	return default;
}
public static async Task<T?> FirstOrDefaultAsyncStruct<T>(this IEnumerable<T> This) where T : struct
{
	return default;
}

[333fred]

IIRC much of System.Linq was left unannotated for .NET Core 3.1. In .NET 5, FirstOrDefault is annotated: https://github.com/dotnet/runtime/blob/release/5.0/src/libraries/System.Linq/src/System/Linq/First.cs#L33

[CyrusNajmabadi]

Meaning, what used to be ambiguous in LINQ before c# 8, doesn't need to be ambiguous anymore.

yes it does. By definition. Code cannot change meaning, or else this will break existing projects. NRT has zero runtime impact on any existing program in any fashion.

[MrTA2]

new List { null }.FirstOrDefault() is invalid today

No it isn't

Yes it is. I get CS8625 in C#8/.NET Core 3.1.

[bbarry]

I think it is going to take a little getting used to unconstrained T? where it is needed and probably will be confusing to some people but there would be downsides to any solution for the problem. The case of FirstOrDefault() doesn't actually need it because it could have been attributed as:

[return: System.Diagnostics.CodeAnalysis.MaybeNull]
public static TSource FirstOrDefault<TSource>(this IList<TSource> source) =>
    ...

but a number of other cases are much more difficult.

[MrTA2]

Meaning, what used to be ambiguous in LINQ before c# 8, doesn't need to be ambiguous anymore.

yes it does. By definition. Code cannot change meaning, or else this will break existing projects. NRT has zero runtime impact on any existing program in any fashion.

Isn't nullable references all about "breaking" (albeit with warnings) existing projects? It does not change runtime behavior. If you have new List<string> { null! }.First().ToUpper() or even without the ! and with a warning, it used to produce a NRE and still produces one now. No impact whatsoever.

[CyrusNajmabadi]

it used to produce a NRE and still produces one now. No impact whatsoever.

That code won't change meaning. However, code that depends on getting 0 back when used on a List<int> will change meaning. That's what is not ok.

[CyrusNajmabadi]

. I know it's difficult to make it do 2 things,

Not only is it difficult, it's outright impossible. This API has shipped. It has had this behavior for 15+ years. There are millions to billions of LOC that depend on it behaving this way. It absolutely cannot change.

[Joe4evr]

Implementing T? with Nullable<T> isn't possible anyway, so that's a moot point.

[333fred]

Right, and I think that's a problem. By making T? do the same thing as the MaybeNull attribute in unconstrained scenarios, the language lost the opportunity to fully implement T? with Nullable<> in the future.

Yes, we acknowledged that when we took the feature. We have 20+ years of api design that uses this form of T?, and no clear path towards generalizing Nullable.

[TahirAhmadov]

Isn't it possible to emit IL which conditionally either a) loads a Nullable, either w/ or w/o a value, and boxes it, for struct types or b) loads the actual reference for class types? Then for struct types, the value is unboxed, and .Value property is used to get to T, when needed? I'm thinking the entire method actually creates 2 bodies; 1 for struct types, and 1 for class types, whenever any usage of unconstrained T? is encountered, then a single conditional "goto" (br) on top does one of 2 things depending on the type. All this happens in IL and C# programmer doesn't have to worry.

Also, even if it's impossible to implement it to do Nullable, why not just leave it as a compilation error? Looks like work was put in to accomplish what was already available by means of attributes and no new advantages were achieved.

[333fred]

Looks like work was put in to accomplish what was already available by means of attributes and no new advantages were achieved.

No, attributes couldn't apply to type parameters used as type arguments. There was no way to express Task<T?>, for example.

As to the generation strategy, it might have been possible given some very complicated and likely expensive implementation, but that wouldn't have rewritten 20 years of api design that uses the nullables we have. Unlike NRT, which was designed to not change implementation, just add annotations, this would massively change implementation. It would require tens of thousands of new apis at least to deal with it, new ways of resolving overloads given these new forms, and would just be generally inconsistent with all of dotnet. If I could go back in time and put nullable into the language from V1, I'd do it in a heartbeat. But unfortunately, we don't have that option.

[MrTA2]

No, attributes couldn't apply to type parameters used as type arguments. There was no way to express Task<T?>, for example.

Fair enough.

As to the generation strategy, it might have been possible given some very complicated and likely expensive implementation,

I understand it would be a significant investment, but imagine how sleek the final solution would be.

but that wouldn't have rewritten 20 years of api design that uses the nullables we have. Unlike NRT, which was designed to not change implementation, just add annotations, this would massively change implementation. It would require tens of thousands of new apis at least to deal with it,

This is the part I'm unable to fully grasp and BTW I do appreciate your effort in replying to this discussion. Allowing nullable unconstrained generic types is a completely new feature in the language and in the .NET CLR in general. What are the APIs that are affected? Yes some new methods can be created using the new feature, like aforementioned Enumerable.FirstOrNull, but that's it - it would be a new method, and it would be a useful new tool for users of BCL. The BCL contributors would not be even obligated to create these new methods (at least immediately), given the simplicity of creating "polyfills".

new ways of resolving overloads given these new forms, and would just be generally inconsistent with all of dotnet.

I think you are referring to hypothetical Foo<T>(T? t) vs Foo<T>(T t). I just had an idea actually. Why not create a new special type, UniversalNullable<T>. Then for both class and struct T, whenever we write T?, it uses that type. Yes, it degrades performance slightly, because even for reference types it has to do a field get behind the scenes, but that's a small performance hit only for the relatively few methods which are going to use this feature. Also this avoids the whole double-generation I thought of earlier. And this solves overloading easily - now T and UniversalNullable are distinct types and both languages and CLR-level method resolution is straightforward. Most importantly, this avoids the need (I think) to make any deep changes to the CLR; just a new type and some compiler shenanigans - which can be copied and pasted from the Nullable compilation logic.