core/recommended lints to support wildcard variables

[pq]

Hey all.

As we wrap up analyzer support for wildcards, we've got some open questions about how we want the linter to behave to support (and nudge folks towards idiomatic use of) wildcards. What opinions would you all like to see enforced in the core or recommended sets?

Feel free to chime in here or dart-lang/sdk#56595

Thanks!

[devoncarew]

At least historically, these two lint sets tend to trail best practices. I.e., we've used a published recommendation in effective dart as a reason to add a lint to these two sets.

Though for some items we've adjusted the lint set to prep best practices for upcoming language changes (i.e., dart-lang/sdk#51221).

[lrhn]

Post feature, I'll want a "no local _ variables" as a core lint.

The only places where _ names make sense are parameters (which you need to have for the signature, but don't need to reference the value of) and destructuring/pattern matching, and pattern matching has internalized _ already.

If you write var _ = 42;, you're missing some point somewhere. It's likely a mistake. That's enough for me to want a core lint to prevent it.
(If you write int _(int x) { return x; }, you're seriously missing something.

I don't know how I feel about avoid_renaming_method_parameters wrt. _. I'd personally be fine with using _ in an override, but I can see why someone using that lint may disagree.
I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

Pre-feature, guiding people away from using _ as a variable name and referencing it is a good idea.
I'd just enable that as a language warning, no lint needed. We're going to change the language in a way that will make that code stop working. That's basically a deprecation warning.

[pq]

Thanks!

I don't know how I feel about avoid_renaming_method_parameters wrt. _. I'd personally be fine with using _ in an override, but I can see why someone using that lint may disagree.

This is in fact how it's currently implemented. And as of dart-lang/sdk@4a7db83,

I'd definitely be fine with an override using a real name where the superinterface used _. It's not a renaming when it started from nothing. It's just a naming.

this too.