Conversation
|
as mentioned above, decided to add some nullability annotations, |
…ks that do not have the nullability attributes
Yes, indeed... :(... 554 files is too much. Even more so, as we recently have merged a larger refactoring PR and I would like to make sure that we are stable before merging "the next big thing". But even if we weren't in that situation, I don't think I would be sensibly able to review this in the next 10 years. It's either take it or not and I don't want to take that responsibility, if something breaks. Not now. Can we find a solution by breaking this into smaller pieces (per project, per feature, ...)? Just to be clear: the huge amount of work is what deterred us from going full NRT in the past and I think that the complexity of introducing NRT in existing codebases (especially ones that are tied to older frameworks and you have to f*** around with ReferenceAssemblyAnnotator, which has not received updates anymore recently) unfortunately currently outweighs its utility in finding bugs. |
The issue in #3280 would never have happened if reference type nullability was enabled in the project.
decided to do something about it.
this focuses mainly on updating annotations (but a very small amount of behavioral changes were made), after I realized the scope of this effort, i focused mainly on this as the annotations should not affect the behavior of the application.
This is the sort of thing i should have asked if it was desired before dumping this on your la, but before i realized i was doing it i was quite a bit into it, so i'm going to throw it and see if it sticks.
Problem
Nullability errors/warnings were not processed.
Solution
return null- make the function return type nullable, annotating out parameters with[NotNullWhen(true)]where appropriate, matching nullability between base classes/ interfaces,