Replies: 5 comments
|
Would these warnings only be suppressed for the "standard" Linq implementations that have the expected semantics, or for all query expressions (even those that do not have the expected semantics)? |
0 replies
|
Note that |
0 replies
|
What's the status of this proposal? |
0 replies
|
Last meeting note link is wrong. Should be this, it seems: https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-04.md#nullable-analysis-of-linq-queries |
0 replies
|
Slightly related: TypeScript added support for this last year: var birds = nations
.map(n => n.getNationalBird()) // getNationalBird returns Bird or null
.filter(n => n != null);
birds.forEach(bird => bird.sing()); // Typescript understands bird will be non-null hereIt's found great use within the TS community. I suspect the same would be true of C#. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Nullable analysis of LINQ queries
Champion issue: #8999
Summary
Nullable analysis of LINQ queries (LDM expressed interested to handle
Where, needs design proposal)Motivation
Range variables in LINQ queries are currently treated as oblivious to minimize annoyances.
Most of the annoyance results from our inability to recognize method calls that filter out
nullelements, such as.Where(i => i is not null).Detailed design
TBD
Unresolved questions
Wheremethods?Design meetings
Split issue from #3868
https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-09-28.md#nullability-improvements
https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-06.md#nullable-analysis-of-linq-queries
All reactions