Exclude switch expression cases from prefer_final_locals lint

[jodinathan]

The prefer_final_locals lint currently triggers warnings for variables declared within switch expression cases. This behavior can lead to unnecessary boilerplate or awkward refactoring, as the cases often represent one-off usage patterns where the enforcement of final adds no clear benefit.

Example

return switch (val) {
  Enum en => () {
    assert(Queryable.words.containsKey(en.name));
    return Queryable.words[en.name];
  }(),
  bool b => b ? 1 : 0,
  _ => val,
};

In this example, the lint suggests making en and b final. However, these variables are implicit, context-specific, and short-lived, making the suggestion less meaningful. Forcing developers to ignore the lint in these scenarios is counterproductive.

Proposed Solution
Update the prefer_final_locals lint to exclude variables implicitly declared within switch expression cases. This would align the lint's behavior with practical usage patterns and avoid unnecessary warnings.

Benefits
Improves developer experience by avoiding irrelevant lint warnings.
Maintains code clarity and reduces the need for lint overrides.
Encourages adoption of switch expressions without friction.

Additional Context
This behavior is similar to how final enforcement is not applied to loop variables in for or forEach constructs, where implicit, short-lived variables are common.

[jodinathan]

it also happens in pattern matching: if (foo case Bar daz) // says [daz] should be final

[dart-github-bot]

Summary: The prefer_final_locals lint flags variables in switch expression cases as non-final, despite their short-lived nature offering no practical benefit. The proposed solution is to exclude these cases from the lint.

[lrhn]

However, these variables are implicit, context-specific, and short-lived, making the suggestion less meaningful.

Not sure what makes them "implicit", they're just as explicitly declared as any other local variable.
They're specific to the context, and the context is a single expression, which can be taken to mean they're likely short-lived ... unless that expression contains a function literal with a statement body. Then the variable can easily survive the expression, and be as long lived as any other captured local variable.

I don't personally care which variables this lint wants to be final (I don't use it), so if function parameters and expression switch pattern variables are not included, then that's a valid choice. It's just a heuristic, there is no language-level difference between different local variables. (Except maybe the catch clause variables of try/catch, those are automatically final).

[jodinathan]

They're specific to the context, and the context is a single expression, which can be taken to mean they're likely short-lived ... unless that expression contains a function literal with a statement body. Then the variable can easily survive the expression, and be as long lived as any other captured local variable.

That’s the point. Short-lived variables are implicitly final, even though they really aren’t.

I don't personally care which variables this lint wants to be final (I don't use it)

Preferring final over var is extremely good for readability. It takes a (short, honestly) time to get used to it but easily pays off.