[inline-classes] Make super an error?

[eernstg]

Thanks for @sgrekhov for noticing this.

The inline class feature specification does not specify the treatment of super in the bodies of instance members.

An expression whose type is an inline class can be the receiver of member invocations where the member is declared in any of its superinterfaces, direct or indirect, as long as the given declaration isn't redeclared by some other declaration with the same name in a "nearer" superinterface. Conflicts are resolved by redeclaring a member with the same name (but it is not required that the redeclaration is a correct override). For example:

inline class A1 {
  final int i;
  A1(this.i);
  void foo() {}
  int get bar => i + 1;
}

inline class A2 {
  final int i;
  A2(this.i);
  void foo() {}
  int get baz => i - 1;
}

inline class B implements A1, A2 {
  final int i;
  B(this.i);
  String foo() => 'B.foo'; // Redeclare, required due to ambiguity.
}

void main() {
  var b = B(10);
  print('${b.foo()}: ${b.bar * b.baz}'); // Prints 'B.foo: 99'.
}

Hence, an inline class cannot treat super in a way that resembles the treatment in a regular class:

super would need to be disambiguated in cases like super.foo() in B. Some proposals were put forward about using constructs like A1.super.foo() to disambiguate the invocation, but those proposals did not receive much support. Moreover, it may be misleading to use super to call A1.foo from B (from the body of B.foo or anywhere else), because it is simply a different member than B.foo (we never choose between A1.foo and B.foo based on dispatch at run time).

If we do come up with a useful treatment of super in an inline class then we will be able to do whatever we want, if it is made an error for now.

I tend to think that we should simply make all occurrences of super in an inline class a compile-time error at this time.

@dart-lang/language-team, WDYT?

[lrhn]

If we allow extends as in #2967, so the inline class doesn't have to declare an instance variable for the representation type itself, we may want to allow calling the extended class's members using super.

[eernstg]

Indeed! That's what I suggested to do with a similar design:

extension class C1 extends C {
  // `super` is an expression with type `C` that denotes the representation object.
}

The point is that the different keywords extension class allow us to optimize for the case where the declaration should add a bunch of sticky extension methods to a given class. If we do get a form of declaration where super is used in that manner then it will probably be even more confusing if super is used by inline classes for some other purpose.

[eernstg]

This has been settled; as of #3364, super in an extension type member is a compile-time error.