Question: C# Nullable Reference Types

[Marv51]

Nullable Reference Types were introduced in C# 8 with .NET Core 3.0. This was never a topic of concern for UWP and WinUI because the .NET Native toolchain never got updated to C# 8.

Now that WinUI 3 is (at least on desktop) based on .NET 5, WinUI should add Nullability annotations to it's public API.

Annotations can be added incrementally, so WinUI could start by annotating some frequently used interfaces.

Is there a plan for this already in place?

I could not find any issue tracking this feature and no entry on the roadmap either.

Related issue for .NET 6: dotnet/runtime#43619
Related tracking issue in communit toolkit: CommunityToolkit/WindowsCommunityToolkit#3958

[jaigak]

WinUI is a Windows Runtime component, not a .NET library and WinRT doesn't have the notion of a nullable reference types.

[Marv51]

@Jaiganeshkumaran I was wondering that, but I guess CsWinRT could generate those annotations, could it not?

@Scottj1s Is that something CsWinRT has thought about? Would be that be even possible?

[huoyaoyuan]

CsWinRT follows the api in winmd. There must be such support in winmd first.

[Marv51]

Custom attributes, similar to SupportedOSPlatform, would be one possible way to go, wouldn't it?

[huoyaoyuan]

The CsWinRT needs information to correctly annotate the apis. If not reading from winmd, there must be somewhere else to tell it which apis are nullable.

[StephenLPeters]

@Scottj1s FYI

[contextfree]

There's actually a proposal to support non-nullable reference type annotations in the WinRT type system and projections here: microsoft/xlang#716 with an associated pull request to the WinRT documentation (which seems to have been abandoned for some reason): microsoft/xlang#708

This would be very helpful for Rust as well.

[Marv51]

Keep alive (re #8638)

[Scottj1s]

@Marv51 given the need to coordinate work in several areas (metadata attributes, WinUI application, midlrt.exe processing, cswinrt.exe processing), I don't see this coming together any time soon. I also don't think the original xlang proposal is practical. Given that nearly all WinRT APIs do not return null references (e.g., constructors would throw some other exception), it seems that the path of least resistance would be to assume NotNull by default and annotate exceptions to that (MaybeNull), and instrument cswinrt.exe to project accordingly (all reference parameters and returns are NotNull unless marked MaybeNull). In any case, I think a proposal needs to be outlined, and benefits described, before work proceeds.