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
[Wildcard Variables] Language Tests in tests/language
#55652
Comments
tests/language
tests/language
cc @dart-lang/language-team I wrote up some potential test cases in this issue. I'm going to start making language tests for the feature. |
Not sure how to read this. (I'm fine with that, but it is outside the "local variables only" constraint that I had understood. But I just checked the spec, and that's what it says. So perfectly fine, just hard to read the phrasing.)
Not sure that needs to be an error. class S {
final int x, y;
S(this.x, this.y);
}
class U extends S {
U(super._ , super._) ;
} looks perfectly reasonable to me. Only the position matters anyway, the names would only be for documentation or accessing in an initializer list. factory S.fwd(int _, int _) = S; (which there is no reason not to allow) then I see no reason to treat Checked the spec. It disallows I'll suggest changing that, and allowing Rest looks fine |
Is this one covered?: Every kind of declaration named The discussion about |
Yeah, it is about generic type parameters. The examples Bob gave were below. I'll name the tests better than these bullets I wrote, hopefully :)
@eernstg What do you mean by the first part of this line? "Every kind of declaration named _ which is specified to be wildcarded is indeed accepted without compile-time errors". Can you explain this a bit more? I'll add "it does not introduce the name _ into the enclosing scope " to the list though, thank you. |
I just meant that we're allowed to use the wildcard feature in all the cases where it should be available. void main() {
int _ = 1, _ = 2; // Should be accepted.
int i = _; // There's no `_` in scope, so this is an "unknown identifier" error.
void localFunction(int _, String _, [Object? _]) { // Declarations OK.
int i = _; // Unknown identifier.
}
} This group of tests would subsume some "doesn't shadow" tests, because that's just one of the consequences of having a declaration that does not introduce a name into the current scope, focusing on the special case where some (directly or indirectly) enclosing scope does have a declaration with the name The reason why I mentioned this criterion is that I think it would be possible to forget one kind of wildcarded declarations, and not get into any conflicts with the other criteria. For example, we should remember that formal type parameters of a class can also be wildcarded: class C<_> {
// Stuff that doesn't actually need access to the actual type argument.
// Also:
List<_> get emptyList => const <Never>[]; // Unknown identifier.
} |
Making language tests in small batches. These are very basic ones to test that you can have multiple local declarations named `_` in the same namespace without a collision error. Bug: #55652 Change-Id: I4d00e9072ba745b363d68db72505c599953c41ad Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/366022 Reviewed-by: Lasse Nielsen <lrn@google.com> Commit-Queue: Kallen Tu <kallentu@google.com> Reviewed-by: Erik Ernst <eernst@google.com>
Write up language tests for the
tests/language
repository.Examples pulled from the spec.
Test Cases
May not be exhaustive.
_
are allowed in function parameters. This includes top-level functions, local functions, function expressions ("lambdas"), instance methods, static methods, constructors, etc. It includes all parameter kinds: simple, field formals, and function-typed formals, etc.:_
are allowed in local variable declaration statement variables._
are allowed in for loop variable declarations._
are allowed in catch clause parameters._
are allowed in generic type and generic function type parameters._
as they are today: top-level variables, top-level function names, type names, member names, etc. are unchanged._
is still a wildcard in patterns_
to a member or top-level declaration._
does still initialize a field named_
(and you can still have a field with that name)_
can't be accessed inside an initializer list._
can be used in the body, but this is a reference to the field, not the parameter._
.super._
as a declaration of a formal parameter in a constructor. This error also occurs in the case where the super parameter has an explicitly declared type and/or default value._
. This means that the representation variable is named_
, and no formal parameter name is introduced into any scopes._
isn't used. (Avoid unused variable warnings.)_
is not introduced into the enclosing scope._
which is specified to be wildcarded is indeed accepted without compile-time errorsThe text was updated successfully, but these errors were encountered: