code generated local variables should be var or final based on enabled lints

[pq]

Specifically, code generation should respect:

• unnecessary_final vs. prefer_final_locals, prefer_final_parameters.

[FMorschel]

I've already worked on (quick fix):

• "Convert 'forEach' to a 'for' loop" should consider prefer_final_in_for_each #56876

And I am currently working on (completion):

• Auto complete on variable destruction can be improved #59854

We also have refactorings to consider here (refactoring):

• Extract variable action should have a final option flutter/flutter-intellij#6304

Do we have anything on what specific features we have that create new variables, @bwilkerson? If we don't, I think I can take a look around this week and find out at least most things.

Your #50018 (comment) (linked above):

It seems like the Dart analyzer ought to be able to determine that a declaration should be var if its redefined, final it is isn't, and const if it is a constant (not sure about that last).

I wish it were that simple. The problem, of course, is that the variable didn't exist before the extract operation, so it's guaranteed that it isn't re-assigned yet. What we can't know is whether the user will assign a new value after this operation.

The point about const is interesting. If the original expression is a const expression, then perhaps we should use const for it. (It isn't guaranteed that that's the right thing either, but it is an interesting signal.)

That said, the original point is valid and something we have been discussing. The question is, what signals can we use to determine the user's preferences? One signal that comes to mind is style-based lints that have been enabled. In this case, it seems clear that if the user has enabled prefer_final_locals then they probably want the variable to be declared using final. The question is whether that's sufficient.

[lrhn]

This is something that user-created code generation might also want to consider.
(Might want code generators to have access to the enabled lints of the repository they're generating into. Alternatively they can just say "generated code should not be linted" and do whatever they want. @davidmorgan)

[davidmorgan]

Thanks Lasse.

For the most part I think "generated code should not be linted" is the right path. We're also talking about arranging for generated code to not be (re)formatted, here dart-lang/build#3812.