[Wildcard Variables] Language Tests in `tests/language`

[kallentu]

Write up language tests for the tests/language repository. Examples pulled from the spec.

Test Cases

May not be exhaustive.

• [x] Multiple _ 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.:

  
  Foo(_, this._, super._, void _(), {_}) {}

list.where((_) => true);

- [x] Multiple `_` are allowed in local variable declaration statement variables.
- [x] Multiple `_` are allowed in for loop variable declarations.
- [x] Multiple `_` are allowed in catch clause parameters.
- [x] Multiple `_` are allowed in generic type and generic function type parameters.
- [x] Other declarations can still be named `_` as they are today: top-level variables, top-level function names, type names, member names, etc. are unchanged.
- [x] `_` is still a wildcard in patterns

int a; (_, a) = (1, 2); // Valid.

- [x] Error if we cannot resolve `_` to a member or top-level declaration.

main() { _ = 1; // Error. }

class C { var _;

test() { _ = 2; // OK. } }

- [x] Wildcards do not shadow.

class C { var _ = 'field';

test() { var _ = 'local';

_ = 'assign'; // Assigns to the field and not the local.

} }

- [x] A positional initializing formal named `_` does still initialize a field named `_ `(and you can still have a field with that name)

class C { var _;

C(this._); // OK. }

- [x] `_` can't be accessed inside an initializer list.

class C { var _; var other;

C(this.): other = ; // Error, cannot access this. }

- [x] The name `_` can be used in the body, but this is a reference to the field, not the parameter.

class C { var _;

C(this.) { print(); // OK. Prints the field. } }

- [x] Error to have two initializing formals named `_`.

class C { var ; C(this., this._); // Error. }

- [x] `super._` will pass on the given actual argument to the corresponding superconstructor parameter.

class B { final ; B(this.); }

class C extends B { C(super._); // OK. }

- [x] An extension type can have a parameter named `_`. This means that the representation variable is named `_`, and no formal parameter name is introduced into any scopes.

extension type E(int ) { int get value => ; // OK, the representation variable name is _. int get sameValue => this._; // OK. }

- [x] No error when a local declaration `_` isn't used. (Avoid unused variable warnings.)
- [x] The name `_` is not introduced into the enclosing scope.
- [x] Every kind of declaration named `_ `which is specified to be wildcarded is indeed accepted without compile-time errors

[kallentu]

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. Let me know if there's something missing or I should test something in particular.

[lrhn]

Multiple _ are allowed in generic type and generic function type parameters.

Not sure how to read this. It's out talking about parameters of genetic function types, or about type parameters? That is, does it allow Function<_, _>() as a genetic function with two anonymous type parameters?

(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.)

Error to have an occurrence of super._ as a declaration of a formal parameter in a constructor.

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. If we allow this._, or a forwarding factory constructor of

  factory S.fwd(int _, int _) = S;

(which there is no reason not to allow) then I see no reason to treat super._ differently.

Checked the spec. It disallows super._ because it breaks the current desugaring specification of super parameters. That's a bad reason for disallowing an otherwise percent good feature, and s good reason for not using desugaring as specification.

I'll suggest changing that, and allowing super._. even if it means treating _ as binding a fresh name, instead of being a non-binding declaration in that case.

Rest looks fine

[eernstg]

Is this one covered?: Every kind of declaration named _ which is specified to be wildcarded is indeed accepted without compile-time errors, and it does not introduce the name _ into the enclosing scope.

The discussion about super._ being an error or not would be taken here: https://github.com/dart-lang/sdk/issues/55661.

[kallentu]

Not sure how to read this.

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 :)

class T<_> {}
void genericFunction<_>() {}
takeGenericCallback(<_>() => true);

Every kind of declaration named _ which is specified to be wildcarded is indeed accepted without compile-time errors, and it does not introduce the name _ into the enclosing scope.

@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.

[eernstg]

What do you mean by ...

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.
}