Language proposal for getting rid of the interface ambiguity of a class with private members

[acarstoiu]

I have reviewed the discussion in #4348 and pondered for a solution to the problem of the two interfaces that a class with own private members has:

• inside the containing library, the interface includes the private members
• outside, it does not.

This flaw is what makes possible that code from the same library, reachable from outside (through exports), taking as input an object of the said class, may discover that the private members are missing from the received object because its type is simply an implementation the public interface.

Illustration (common knowledge)

/* This is 'a.dart'. */

class I {
  int get a => 10;

  void _do() {
    print("Doing stuff in I");
  }
}

class II {
  void _do() {
    print("Doing stuff in II");
  }
}

void doWith(I i) => i._do();

/* Run this file.*/

import "a.dart";

class AI /*extends II*/ implements I {
  @override
  int get a => 11;

  void _do() {
    print("Doing stuff in AI");
  }
}

void main() {
  doWith(AI());
}

The code above throws NoSuchMethodError.
Off topic, can anyone explain why the code works and prints Doing stuff in II if the comment delimiters around extends II are removed? 🤨 Is the compiler happy with any implementation of the private method _do(), as long as it originates from the same library, namey the totally unrelated class II ❓

Proposal

Just go bold with the considerations made in this doc section (yeah, I discovered afterwards that my idea wasn't that original): any class (or mixin) with own private members should be implicitly marked with the base modifier. As this modifier is infectious (i.e. it applies to all inheriting classes, be them direct or indirect descendants), the containing library's code will never get unpleasant surprises with objects passed from outside.

If the class in question is not exported (including private), no harm is done. If the class is exported, any implementation outside the containing library will turn into broken code and require refactoring, which is not trivial when the implementing class already extends some other class (than Object).

[lrhn]

It may be surprising to users that a class is base without it being explicitly written.
A more consistent design would be to require the class to be base or final if it is non-sealed and has a private instance member, and only final if the private instance member does not implement its interface.

A sealed class cannot be base or final, but its subclasses must be within the same library, and then they'll have to be sealed, base or final.

("final if doesn't implement interface" requirement is to prevent having an abstract private instance member that subclasses must implement. Even if the class is base, a subclass in a different library still cannot implement the interface.)

Sounds like something you can do with a lint.
Feels very intrusive to add it to the language now.
It will require splitting some interfaces from their implementation. Today you can make an interface class, and make it also be the default implementation of the interface. You have to be careful to not assume other implementations of the interface have private members, but you avoid having to create a second class and a forwarding factory constructor.

[acarstoiu]

A more consistent design would be to require the class to be base or final if it is non-sealed and has a private instance member, and only final if the private instance member does not implement its interface.

This would be the verbose way of enforcing this rule. Fine by me.

Sounds like something you can do with a lint.

Only as a preparation for the next major language version when it would become a rule, not just a recommendation.

Feels very intrusive to add it to the language now. It will require splitting some interfaces from their implementation.

Yes, we end up with the sane way of defining interfaces, i.e. public members only. The Dart shortcut of using a class as an (already implemented) interface would still be possible under this condition.