Language: Do implementers have to implement private members?

[wytesk133]

On DartPad, the following code does not compile

class A {
  int thisIsPublic;
  int _thisIsPrivate;
}

class B implements A {
  @override
  int thisIsPublic;
}

The error is The non-abstract class 'B' is missing implementations for these members: - A._thisIsPrivate.

Do implementers have to implement private members?

[renefloor]

The dart docs says so yes:

// A person. The implicit interface contains greet().
class Person {
  // In the interface, but visible only in this library.
  final _name;

(https://dart.dev/guides/language/language-tour#implicit-interfaces)

Note "visible only in this library", is you do class B implements A in another library (or even just another file) you don't have to implement the private members.

[pedromassango]

Thanks. Those details are very important to keep in mind

[hugocbpassos]

This approach doesn't seem safe to me. Consider:

library a;

import 'b.dart';

void main() {
  B()._thisIsPrivate; // NoSuchMethodError: Class 'B' has no instance getter '_thisIsPrivate'.
}

abstract class A {
  int thisIsPublic;
  int _thisIsPrivate;
}

library b;

import 'a.dart';

class B implements A {
  @override
  int thisIsPublic;
}

Now is too late to change this, but just for discussion matters, why not demanding implementations from different libraries to implement private members? Of course it would prevent implementations of classes with private members, but isn't safety more important?

[eernstg]

@wytesk133 wrote:

Do implementers have to implement private members?

Yes, the basic rule is that it is an error if a subtype (implements, not extends) does not have an implementation of a member, private or public.

However, Dart used to be a much more dynamically checked language than it is today, and the treatment of missing private members across different libraries is a corner of the language where sound static checking has not (yet) been introduced, so there is indeed a potential for an error at run time which is not flagged at compile-time, as shown in @hugocbpassos' example here.

It wouldn't be difficult at all to flag this error at compile-time, but it is a breaking change, which is the main reason why it hasn't been done.

It would actually be a very good candidate for a lint, cf. https://github.com/dart-lang/linter/issues/2125.