Repository navigation
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
nullconstructs 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).LengthNo warning, throws NRE.
Possible workarounds
No response
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
kerams commentedon Aug 14, 2024
Desribed in https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1060-nullable-reference-types.md#meaning-of-unbox, perhaps forgotten or ignored for the time being?
T-Gro commentedon Aug 14, 2024
I think there are two perspectives:
[NotNullIfNotNull]in C# flow analysis), even though this might complicate downcasting-heavy code.This is further complicated by the fslib Unboxing functions doing a runtime lookup, where nullness information is no longer known.
A solution which would insist on downcasting a nullable source into a nullable target (
:?> string | null) would only work on target types which can carry nullness, which is not equal to all types that can be downcasted to (tuples, anon records).T-Gro commentedon Aug 14, 2024
A safe but not all-scenarios-covering change would be:
| null, report a nullness warning if it isn'tWould that meet the expectations here?
charlesroddie commentedon Oct 2, 2024
This shouldn't throw an NRE but should throw an exception during the
:?>stringcast.f(x: string | null) = x :?> stringshould succeed ifxis astring, and fail ifxisnull(since, post NRTs,nullis not astring).No separate warning should be given since now new danger is introduced:
:?>is known to throw if the LHS is not of the type on the RHS.If there is a warning it should apply to all uses of
:?>("don't use this").kerams commentedon Oct 2, 2024
Feel free to take up that breaking change (which is what a different exception constitutes, I think) with the runtime team (unless you're suggesting F# should start injecting extra null checks before the
unbox.anyinstruction).T-Gro commentedon Nov 25, 2024
Fixed by #17965