Retroactive compiler bugfix allowing null conditionals to evaluate to pointer types

[jnm2]

Since no language in the specification specifically prevents a?.B when B has a pointer type, the language design team has decided to enable this syntax for all language versions (back to 6) and consider it a compiler bugfix. It is not a breaking change.

Would we like to do anything in the spec to clarify one way or the other?

LDM notes (https://github.com/dotnet/csharplang/blob/main/meetings/2025/LDM-2025-12-17.md#null-conditionals-evaluating-to-a-pointer-type):

Null-conditionals evaluating to a pointer type

Issue: dotnet/roslyn#7502
Spec: https://github.com/dotnet/csharpstandard/blob/41694caebb0fb759b75ef66b9d11d37006aab000/standard/expressions.md#12813-null-conditional-element-access

Next up, we discussed a potential compiler bug/specification bug. This has been open for a long time, but was recently resurfaced and we wanted to investigate to clarify our definitions. The question hinges on what the definition of what a non-nullable value type is. If a pointer is a non-nullable value type, then the rules as written state that the type would have to be Nullable<int*>, which is indeed illegal. But if pointers are not non-nullable value types, then the cases would fall through to the last bullet of the spec and it should just work, as the specified transformation would be legal for a pointer. Certainly on the surface, pointer types are nullable: int* i = null; is legal, as is comparing them with null. Given that, and the definitions in §8.2.1, we are comfortable treating this as a compiler bug, and will fix it to work. We will also leave the decision on clarifying the specification further to the ECMA 334 committee.

Conclusion

Null-conditional expressions that produce a pointer type not being allowed is a compiler bug and will be fixed as such.