Add rules about super and extension types to wildcard spec (#3729)

Add rules about super and extension types to wildcard spec

Author: eernstg

working/wildcards/feature-specification.md

@@ -4,7 +4,7 @@ Author: Bob Nystrom
 
 Status: In-progress
 
-Version 1.0
+Version 1.1
 
 Pattern matching brings a new way to declare variables. Inside patterns, any
 variable whose name is `_` is considered a "wildcard". It behaves like a
@@ -99,8 +99,8 @@ A *local declaration* is any of:
 *   For loop variable declarations.
 
     ```dart
-    for (_ = 0;;) {}
-    for (_ in list) {}
+    for (int _ = 0;;) {}
+    for (var _ in list) {}
     ```
 
 *   Catch clause parameters.
@@ -117,11 +117,12 @@ A *local declaration* is any of:
 
     ```dart
     class T<_> {}
+    void genericFunction<_>() {}
 
     takeGenericCallback(<_>() => true);
     ```
 
-A local declaration whose name is `_` does not bind anything to that name. This
+A local declaration whose name is `_` does not bind that name to anything. This
 means you can have multiple local declarations named `_` in the same namespace
 without a collision error. The initializer, if there is one, is still executed,
 but the value is not accessible.
@@ -138,12 +139,12 @@ class C {
   var _ = 'bound';
 
   test() {
-    print(_); // Prints "bounnd".
+    print(_); // Prints "bound".
   }
 }
 ```
 
-Likewise with a top-level named `_`:
+Likewise with a top-level declaration named `_`:
 
 ```dart
 var _ = 'ok';
@@ -207,8 +208,8 @@ quite confusing. In practice, we expect reasonable users will not name fields
 
 ### Initializing formals
 
-An initializing formal named `_` does still initialize a field named `_` (and
-you can still have a field with that name):
+A positional initializing formal named `_` does still initialize a field
+named `_` (and you can still have a field with that name):
 
 ```dart
 class C {
@@ -218,17 +219,29 @@ class C {
 }
 ```
 
+*Note that it is already a compile-time error if a named initializing
+formal has the name `_`. This is a special case of the rule that it is an
+error for a named formal parameter to have a name that starts with `_`.*
+
+```dart
+class C {
+  var _;
+
+  C({this._}); // Error.
+}
+```
+
 But no *parameter* with that name is bound, which means `_` can't be accessed
-inside the initializer list. In the body is fine, since that refers to the
-field, not the parameter:
+inside the initializer list. The name `_` can be used in the body, but this
+is a reference to the field, not the parameter:
 
 ```dart
 class C {
   var _;
   var other;
 
   C(this._)
-    : other = _ { // <-- Error. No "_" in scope.
+    : other = _ { // <-- Error, cannot access `this`.
     print(_); // OK. Prints the field.
   }
 }
@@ -244,6 +257,68 @@ class C {
 }
 ```
 
+### Super parameters
+
+An occurrence of `super._` as a declaration of a formal parameter in a
+constructor is a compile-time error. This error also occurs in the case
+where the super parameter has an explicitly declared type and/or default
+value.
+
+*`super._` is not an error everywhere: In a method body it could be an
+invocation of an inherited getter named `_`.*
+
+```dart
+class B {
+  final _;
+  B(this._);
+}
+
+class C {
+  C(super._); // Error.
+}
+```
+
+*The desugared meaning of a super parameter includes a reference to the
+parameter in the initializer list of the enclosing constructor declaration,
+but such references are not possible when the parameter name is a
+wildcard.*
+
+*It may seem inconvenient that `super._` "does not work" in the last
+example, but we do not wish to create exceptions about the ability to refer
+to a declaration whose name is a wildcard, just so we can support this
+particular usage. The advice would be to use a different name than `_` for
+the instance variable in `B` in the first place, or using a different name
+in `B` and possibly `// ignore` a lint that may warn about the names being
+different.*
+
+### Extension types
+
+An extension type declaration has a `<representationDeclaration>`
+which is similar to a formal parameter list of a function declaration.
+
+*It always declares exactly one mandatory positional parameter, and the
+meaning of this declaration is that it introduces a formal parameter of a
+constructor of the enclosing extension type as well as a final instance
+variable declaration, also known as the representation variable of the
+extension type.*
+
+This parameter can have the declared name `_`. This means that the
+representation variable is named `_`, and no formal parameter name is
+introduced into any scopes.
+
+```dart
+extension type E(int _) {
+  int get value => _; // OK, the representation variable name is `_`.
+  int get sameValue => this._; // OK.
+}
+```
+
+*Currently, the formal parameter introduced by a
+`<representationDeclaration>` is not in scope for any code, anyway.
+However, future generalizations such as primary constructors could
+introduce it into a scope. At that time it does matter that there is no
+formal parameter name.*
+
 ### Unused variable warnings
 
 Dart tools currently warn if you have an unused local declaration. If the
@@ -319,3 +394,13 @@ public API.
 However, this *is* a breaking change. If this ships in the same version as
 pattern matching, we can gate it behind a language version and only break code
 when it upgrades to that version.
+
+## Changelog
+
+### 1.1
+
+- Add rules about `super._` and about extension types.
+
+### 1.0
+
+- Initial version