Skip to content

Nullness issue - Downcasting should preserve nullness information #17532

Description

Issue description

Downcasting is an operation that returns null when input is null. However, when the explicit coercion type is not nullable, the downcasting result currently won't be nullable either. Either a nullable type should be required (:?> string | null) or the downcasting operator should automatically adjust nullness based on the input type.

Choose one or more from the following categories of impact

  • Unexpected nullness warning (false positive in nullness checking, code uses --checknulls and langversion:preview).
  • Missing nullness warning in a case which can produce nulls (false negative, code uses --checknulls and langversion:preview).
  • Breaking change related to older null constructs in code not using the checknulls switch.
  • Breaking change related to generic code and explicit type constraints (null, not null).
  • Type inference issue (i.e. code worked without type annotations before, and applying the --checknulls enforces type annotations).
  • C#/F# interop issue related to nullness metadata.
  • Other (none of the categories above apply).

Operating System

Windows (Default)

What .NET runtime/SDK kind are you seeing the issue on

.NET SDK (.NET Core, .NET 5+)

.NET Runtime/SDK version

9.0.0-preview.7.24405.7

Reproducible code snippet and actual behavior

((null: obj | null) :?> string).Length

No warning, throws NRE.

Possible workarounds

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions