Consider enabled lints when performing refactorings

[pq]

Concrete example: extract variable could insert a final modifier if prefer_final_locals is enabled.

See: Dart-Code/Dart-Code#1949.

/cc @bwilkerson @scheglov

[scheglov]

https://dart-review.googlesource.com/c/sdk/+/115065 for prefer_final_locals.

[JamesMcIntosh]

Is it possible for omit_local_variable_types: false to be considered too so that it automatically adds the type to local?

[bwilkerson]

Assuming I'm understanding the question, my answer is that I think we don't want to confuse the absence of a signal with a negative signal (and disabling a lint simply removes it from use, it doesn't mean that the opposite is intended).

That said, I believe that always_specify_types provides the positive signal that you're thinking of, and could reasonably be used to cause a type to be added.

[JamesMcIntosh]

Hi @bwilkerson, thanks for explaining about the absence of a signal.

I like your idea about using always_specify_types: true as a way to determine if the local variable's type is required.

The thing which sacred me most about enabling always_specify_types on an existing code base is the sheer number of closures which then require types. I just found avoid_types_on_closure_parameters: true lint, no excuses now not to try it!

[bwilkerson]

I just found avoid_types_on_closure_parameters: true lint ...

Unfortunately, I believe those two rules collide. That is, I suspect that if you enable both then one will produce a lint when a closure's parameter has no type and the other will produce a lint when the parameter has a lint. We might want to consider making lints aware of other lints as well.

[JamesMcIntosh]

You are correct, they do conflict with each other. I think the docs needs a note added like there is for omit_local_variable_types while they remain unaware of each other.

https://dart-lang.github.io/linter/lints/avoid_types_on_closure_parameters.html
https://dart-lang.github.io/linter/lints/always_specify_types.html