Unexpected nullability warning in null-coalescing throw expression

[JeroenBos]

Consider the following snippet:

object?[] a = ...
object[] b = a!; // no warning
object[] c = a! ?? throw new Exception(); // warning CS8619?! (Nullability of reference types in value of type 'object?[]' doesn't match target type 'object[]')

I don't expect the warning because of the null-forgiving operator, and because the throw_expression has influence the nullability of the RHS (right?). The inferred type of the RHS is inferred from two operands: one has a type, object[], and the other has no type. object[] is assignable to the LHS's type -without warning-, so I don't see how unifying with an expression that doesn't have a type would alter that?

As a workaround I found that I can assign into a temporary variable:

object[] tmp = a!;
object[] d = tmp ?? throw new Exception();

But this feels awkward and it's unintuitive why the temporary variable prevents the warning. Why a warning?

[chrisoverzero]

The null-coalescing operator would help if the array were nullable. The type object?[] is a non-nullable array of nullable elements.

By coalescing, you’re telling the flow analysis, “Never mind what I said before, it could be nullable.”

[JeroenBos]

Sure, but I'm not talking about a nullable array, but about an array whose elements are nullable. The ! also suppresses when the nullability of the elements don't match, like in my b = a! example. And for that matter, object[]? c = a! ?? throw new Exception(); still gives the same warning.

[jnm2]

This would be a smaller step than going all the way to a temporary variable:

object[] c = (a ?? throw new Exception())!;

It makes sense that it would work this way since the ! is targeting the assignment, whereas in your example the ! is targeting the ??.

[333fred]

Correct. The null forgiveness operator doesn't magically make nested nullability go away: it changes top-level nullability, and silences warnings. You need to use it where the warning is.