LanguageFeatures/Super-parameters/semantics_A06_t19

[scheglov]

LanguageFeatures/Super-parameters/semantics_A06_t19: Fail
LanguageFeatures/Super-parameters/semantics_A06_t20: Fail
LanguageFeatures/Super-parameters/semantics_A06_t23: Fail
LanguageFeatures/Super-parameters/semantics_A06_t24: Fail
LanguageFeatures/Super-parameters/semantics_A06_t25: Fail

Code like:

class S {
  int s1;
  S(int x1) : s1 = x1;
}

class C extends S {
  int i1;
  int i2;
  C(this.i1, super.s1, int x) : this.i2 = x;
//           ^^^^^^^^
// [analyzer] unspecified
// [cfe] unspecified
}

Here, it is OK to use super.s1 - it is the 1th super-formal in C, and its associated super-constructor parameter is x1. The spec says "If p is a positional parameter, let j be the number of positional super-parameters of C up to and including p in source order. The associated super-constructor parameter of p is the jth positional parameter of D (1-based), if D has that many positional parameters."

[scheglov]

co19/LanguageFeatures/Super-parameters/type_inference_A06_t03

[sgrekhov]

@eernstg please confirm. According to the spec

Each super-parameter, pn with name n and (inferred or declared) type Tn, introduces a final binding with the same name n and static type Tn into the initializer list scope (just like initializing formals).

We are introducing name s1 into initializer list but we already have member with the same name there. Isn't it a name conflict?

[eernstg]

No, the instance member named s1 can be accessed in a context where no other declaration shadows it and there is access to this (for instance, class C2 extends S { void foo() { print(s1); }}). There is never a name clash in the case where a declaration shadows another one (class C3 extends S { void foo(bool s1) { print('$s1 is a parameter, ${this.s1} is an instance variable'); } }), the shadowing simply works by letting the innermost declaration win, but we may be able to use mechanisms like this. in order to access the shadowed declaration.

We could have a name clash in the initializer list scope:

class S {
  int s17; // It doesn't matter whether this is called `s1` or `s17`.
  S(int x1) : s17 = x1;
}

class C extends S {
  C(Whatever s1, super.s1); // Error: `s1` declared twice in the same scope.
}

The sentence from the feature spec simply says that the declaration super.s1 introduces the name s1 into the initializer list scope (such that we can have initializer list entries like assert(s1 != 42)), and that will refer to the parameter, not the instance variable.

But in the body of the constructor, s1 will refer to the instance variable, because the parameter is not in scope. So, e.g., we can use the getter and the setter, whereas an assignment to the parameter is an error:

class S {
  int s17;
  S(int s1) : s17 = s1; // Let the two associated parameters have the same name.
}

class C extends S {
  int i1;
  int i2;
  C(this.i1, super.s1, int x) : this.i2 = (s1 = x) {// Error, `s1` is final.
    s1++; // OK: Refers to the getter and setter of the instance variable.
  }
}

I used the same name for the super parameter and for the parameter that it is associated with, just to make the code easier to read.

However, the scoping is handled differently by the CFE and the analyzer, so I created dart-lang/language#2056 to clarify the desired scoping.

[sgrekhov]

Thank you for detailed reply!

[sgrekhov]

@scheglov sorry for numerous errors and typos in a Super parameters test. But it's really hard to write tests for the new language feature without a compiler

[scheglov]

No problems at all. Thank you for writing these tests!