-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Lint when using variable named _
#51221
Comments
Does it need to report every use of a variable, or only the first use? I'm thinking the latter would be a better UX, but there might be reasons for the former that I'm not thinking about. |
Worth calling out that this lint should not fire on uses of members (or at least constructors) named |
I was just about to comment that this should just apply to all declarations, but this is a good point :(. Feels weird to special case constructors too. |
Yeah, I was deliberate in my wording but I should have emphasized the "parameters and local variables" bit. |
I do think that a constructor named |
The constructor |
The language specification has used the terminology "a constructor named (As an aside, this terminology ensures that no constructors are anonymous/nameless (but a constructor can have the same name as the enclosing class), and it is consistent with the actual syntax that denotes a constructor in an instance creation (and constructor tear-offs are not that different). So I'd recommend that we just use this terminology. ;-) I believe this would make it possible to use the following definition of the lint:
This will not flag instance creations like Should we also emit 'deprecated choice of name' diagnostics for every declaration named |
Warning about every declaration named There are places where we'd want to allow
That's places where a name is required, but we may not care about the value. A local variable declaration of Non-local variable or function declarations named If we push this as lints, and people follow it, there will never be a |
Very good, then we have a good estimate of where to warn: Everywhere else. ;-) |
There was a comment elsewhere that some people are doing:
to attach metadata to an expression, because we only allow metadata on declarations. |
If we define that those don't actually introduce a local variable into the scope, then we just have some special type of declaration for those, which is the only thing allowed to have the name |
Regarding metadata given this is always a local (and trivial) change I would just not allow it, force those to have a real name. |
This lint request explicitly says "The lint wouldn't warn if you declare a variable or parameter named _." This is about uses, not declarations. |
@munificent: assuming the wildcard proposal still has traction, do we want to push ahead on this? |
We didn't get the wildcard proposal done in time for 3.0, but I think there is still generally a desire to move in that direction, yes. I think the lint is definitely valuable. |
Lint proposal cooking: #59157 |
The |
Yes, we should definitely aim to get this into the core lints IMO, at least once we've shaken it out. cc @devoncarew @natebosch @mit-mit @lrhn |
I'm going to close this as completed as Thanks everyone! If you'd like to see anything further done to the lint, please open a new issue. As for its inclusion in the core lint set, please open a new issue at https://github.com/dart-lang/lints/issues to suggest a new major release if it's necessary for that to occur earlier than the normally scheduled release. |
Inside a pattern, an identifier named
_
is a non-binding wildcard. This means you can use it more than once without a collision error:With patterns, we are not changing the behavior of declarations named
_
outside of patterns. So this still works:But we would eventually like to change the language so that (at least) parameters and local variables named
_
become non-binding.This change is breaking because currently those identifiers are binding and can be used. It's rare for users to refer to parameters and variables named
_
, but I do see some examples of it in the wild.To ease that transition, we could add a lint that fires whenever you use a parameter or variable named
_
(or any sequence of only underscores,__
,___
, etc.) The lint would suggest that they pick another name for the variable if they're going to refer to it. The lint wouldn't warn if you declare a variable or parameter named_
. That's fine. It should only be a violation to have an identifier expression or assignment target that uses one of these variables.That should make it less breaking to make
_
non-binding in a later Dart release.cc @dart-lang/language-team
The text was updated successfully, but these errors were encountered: