Nullness issue - Option.toObj infers input to be an option of a nullable type
- Dominant language
- F#
- Stars
- 4.3k
- Forks
- 876
- Avg merge
- 4d 22h
- Merged PRs (30d)
- 144
Description
### Issue description
When trying to pass a `string option` value to a null-agnostic method taking `string` using `Option.toObj`, the input type gets inferred as `string | null option`.
### 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`).
- [X] 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.100-rc.1.24452.12
### Reproducible code snippet and actual behavior
```fsharp
// assembly A, null-agnostic
let work (x: string) = ()
// assembly B, null-aware
let whatever x =
work (Option.toObj x)
```
The type of `whatever` is inferred to be `string | null option -> unit`, but `string option -> unit` seems more reasonable.
### Possible workarounds
```fsharp
let whatever (x: string option) =
work (Option.toObj x)
```
Contributor guide
Assessment
This issue has not been assessed yet.