Class can claim to implement an interface even if the other has privates

[Hixie]

File A:

class A {
  void public() { }
  void _private() { }
}
void test (A x) { x._private(); }

File B:

import 'A';
class B implements A {
  void public() { }
}
void main() {
  test(new B());
}

This code has no analyzer warnings, despite being guaranteed to crash.

[lrhn]

Yes, that's a known feature.
Inside a library, the interface of a class declaration also contains the private members, outside of the library it only contains the visible members. The uses the wording "accessible" when talking about these members, and it's only a warning if a non-abstract class' interface contains an accessible member which isn't implemented by the class. If the member is not accessible, there is no warning.

So, general rule: Don't expose a public interface with private members, and assume that the instances of that type will have those members (well, not if you get those instances from someone outside the library, if they are all created inside the library, then you can assume it - and "this" will have them).

I guess the analyzer could hint about such a problem if we can detect it safely enough to not cause too many false warnings. It's perfectly OK to have private members. It's just not OK to get an instance as a parameter to a public method and assume the instance knows about the private members.

[Hixie]

The problem is that this affects all classes ever. You're basically saying "don't use privates in publicly visible classes", which is untenable IMHO.

[Hixie]

(It would be different if you could distinguish "interfaces" from abstract base classes.)

[lrhn]

You can use private members in publicly visible classes, and we do it all the time.

When a class is both used as an interface and a default implementation, that only works because the private members used by the implementation doesn't leak into the exported interface.
It does mean that you have to be careful what you assume. You can use the private members on this and on any instance you have created yourself, but if you get an instance from the outside, you should not assume that the private members are there - but the type system can't enforce that.

If we removed the private members from the interface inside the declaring library, then a lot of existing code would start warning. Something like Foo foo = new Foo(42); foo._initialized = true; would warn even if I am completely sure that it's the right kind of Foo.
So, it's a trade-off. If we had a way to express both the external interface and the internal interface, then we could annotate appropriately, but there is only one interface introduced per class - which, technically, includes all the private members, it just doesn't warn if you don't implement something you can't see.

You can actually see that the interface contains the inaccessible members:

library a;
import "b.dart";
class A {
  int _foo = 42;
}
abstract class C extends B {  // Abstract because otherwise it would need to implement _foo.
  foo() { print(_foo); }  // No warning because _foo is inherited from B;
}

library b;
import "a.dart";
class B implements A {}  // No warning, doesn't implement "_foo", but it's not accessible.

[Hixie]

Flutter has a number of tree structures that are designed to have an internally-defined abstract base class that you (as an author) subclass, and then the subclasses are instantiated and connected into a tree. The base class has private and public members; the public API uses these privates for all the logic the class hierarchy exposes.

Obviously, given such a design, if you say your class "implements" the Flutter-defined abstract base class but doesn't actually "extends" it, then everything will break. Pretty much as soon as you hand in the class to the aforementioned public methods, they'll crash, much as if you'd handed in a "Timer" or "FileSystemEntity" or a "Vector3" instead of the actual expected type.

The difference is that the analyzer will not report any problems, like it would if you did try to pass in a "Timer" or "Vector3". It will happily say that all the contracts are met. If the class only uses the privates for some rare cases, then you might not know that anything is wrong for quite some time.

[zoechi]

You could implement an private interface abstract class _MyTreeItem{} and check for is _MyTreeItem instead, just as a workaround.

[Hixie]

That would be a runtime check. What I would much rather have is an analyzer-level check.

[leafpetersen]

We've talked about supporting something like a NoImplicitInterface annotation on classes for DDC/strong mode that prevents other classes from "implementing" them (only extension allowed). You'd have to mark the class explicitly yourself though.

cc @vsmenon

[bwilkerson]

We've talked about something similar for the analyzer code base, but actually want something more general. I want to be able to mark each public class to indicate which uses of that class we are committing to support (implement, extend, mix in, some combination, or none of the above) so that clients know what is and isn't safe to count on in terms of backward compatibility.