Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New lint to make parameters/variables/fields non-nullable if ! is used unconditionally for them. #58674

Open
polina-c opened this issue Mar 3, 2022 · 3 comments
Labels
area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) devexp-linter Issues with the analyzer's support for the linter package linter-lint-request P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@polina-c
Copy link
Contributor

polina-c commented Mar 3, 2022

For example, for the code

void hello(String? name){
  print('Hello, ${name!.trim()}!');
}

the lint would suggest:

void hello(String name){
  print('Hello, ${name.trim()}!');
}
@polina-c polina-c added type-enhancement A request for a change that isn't a bug linter-lint-request labels Mar 3, 2022
@bwilkerson
Copy link
Member

At the very least, the lint would need to not flag parameters in methods that override another.

I have to wonder whether there are other cases that would need to be taken into account.

@srawlins
Copy link
Member

srawlins commented Mar 4, 2022

Another would be the case of the function being passed as a tear-off to some location that requires function with a nullable parameter.

typedef Fn = void Function(int?);
void f(int? i) {
  i!;
}
void g(Fn) {}
void main() {
  g(f);
}

@jacob314
Copy link
Member

jacob314 commented Mar 4, 2022

There are reasonable cases where a developer might want to make a parameter to a method nullable but fail any time it is not null so this lint may have too many false positives. For example, methods in a test framework could frequently have this pattern.

However, right now the null safety migration tool may generate cases like this fairly frequently so it would be nice to give users a hint that this pattern usually indicates code they could have written more cleanly. Perhaps this is a good case for a suggestion level lint that only shows up in IDEs and code reviews when you modified the method using this pattern. It would be great if while reviewing a null safety migration CL I saw each case like this so I could make sure it was intentional rather than an indication of an API that had been migrated poorly.

@devoncarew devoncarew added devexp-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Nov 19, 2024
@devoncarew devoncarew transferred this issue from dart-archive/linter Nov 19, 2024
@pq pq added the P3 A lower priority bug or feature request label Nov 20, 2024
@bwilkerson bwilkerson added area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) and removed area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Feb 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-devexp Developer Experience related issues (DevTools, IDEs, Analysis Server, completions, refactoring, etc) devexp-linter Issues with the analyzer's support for the linter package linter-lint-request P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants