Repository navigation
Better diagnostics for mixing different nullness pattern matching ways #17432
Description
There are 2 ways to do null-related pattern matching now:
let len1 (str: string | null) =
match str with
| Null -> -1
| NonNull s -> s.Length
let len2 (str: string | null) =
match str with
| null -> -1
| s -> s.LengthBoth produce no warnings, all good. What I don't like is the behavior when we start mixing those two approaches:
let len3 (str: string | null) =
match str with
| null -> -1
| NonNull s -> s.Length warning FS3262: Value known to be without null passed to a function meant for nullables: You can remove this |Null|NonNull| pattern usage.
let len4 (str: string | null) =
match str with
| Null -> -1
| s -> s.Length warning FS3261: Nullness warning: The types 'string' and 'string | null' do not have compatible nullability.
As a user I just want consistent diags here in the spirit of "hey, pick one way or another, don't mix things up" - ideally with exact pointers what to change but that's an extra.
I think such errors can happen really often because of fatfingering or copypasting - and casing differences are not even very noticeable, so there is accessibility in the game as well.
Originally posted by @psfinaki in #15181 (comment)
Activity
T-Gro commentedon Jul 31, 2024
Related to #17409
T-Gro commentedon Jul 31, 2024
Might be implicitely solved by contextual information to nullness diag (... "possible derefence"..)
T-Gro commentedon Jul 31, 2024
Idea: Make the active pattern |Null|NonNull| to an module which needs explicit opening or explicit prefixing.
T-Gro commentedon Jul 31, 2024
Idea: RQA for the active pattern:
smoothdeveloper commentedon Jul 31, 2024
What is the main reason for those patterns to exist?
I find matching on literal
nullis most natural thing to do.I'd favour explicit opening but no RQA attribute as it makes it really inconvenient to use for those that prefer it.
T-Gro commentedon Aug 1, 2024
The active pattern can eliminated nullness from a type (i.e. what you match as values will be known to be non-nullable) even in deeply nested scenarios. Imagine a
string | nullfield within record, being wrapped in voption, within another record.The the classical
nullliteral this only eliminated nullness on first level values, but not from nested members of types.From it's signature,
NonNullwill give you a value known to be not null.