Review spec regarding expressions without types

[RexJaeschke]

This more general issue arose when we discussed PR #1515: “Address remaining nullable reference type issues” on the 2026-01-14 call.

[jskeet]

To give more detail: this is about the null state of expressions without a type. We already have that the null state of an expression of null is "maybe null" but there are other expressions without a type, notably anonymous functions and method group conversions.

I think we can say that the state of anonymous function expressions and method group conversions is "not null" (as any conversion from those expressions to a value will lead to a non-null value). We should check what other expressions may not have a type though.

[jskeet]

Ooh, tuple literals may not have a type either, e.g. (null, null). When converted to object, the value would never be null (even if all elements are) - does that mean we should say a tuple literal has a state of "not null"? I suspect so.

@BillWagner can you think of other kinds of expression which may not have a type?

[Nigel-Ecma]

[I am on a break, really, but I need to check my email for other reasons and so I read some of the messages filling up my mailbox… Silly me 🙁]

Dare I suggest, as I undoubtedly have before, that the null state of anything is part of the implementation specific nullable analysis and so doesn’t nee dto be specified and hence saves TG2 work? If nullable analysis is not implemented, or disabled, is the nullable state of any relevance? Is an implementation non-conformant if it determines different null states than some other implementation? Or if it has a different set of null states? Is TG2 not just generating work for itself?

[BillWagner]

@jskeet A tuple literal is a value type, so nullable analysis doesn't apply: It's always non-null.

[jskeet]

@BillWagner: I agree it's always a value type, even if we don't know what the type is - but it's unclear to me whether that's really covered by anything. (I think we may be missing coverage of value types in general - we cover it for default expressions, but only those...)