public_member_api_docs: constructors on sealed classes are not really public

[matanlurey]

Similar to #57361 (/cc @yjbanov).

Here is a more recent (2023-era) problem, constructors that are not really public.

Consider:

sealed class Fruit {
  Fruit();
}

final class Apple extends Fruit {}
final class Orange extends Fruit {}
final class Banana extends Fruit {}

The Fruit() constructor appears public (i.e. it does not start with _), but in Dart 3+, it is functionally private (that is, it's only accessible in the same library, similar to methods declared with _).

[lrhn]

The class is abstract (so constructor cannot be called or torn off) and cannot be subclassed, so there is indeed no valid way to use the constructor.

The constructor could just as well have been private.
It would make sense for, e.g., dartdoc to omit any reference to the constructor, similar to constructors of abstract interface or final classes.

In which case it also shouldn't count as public API.

[pq]

Following the lead of #59189, I think we want to extend this to similarly skip generative constructors in classes that are

• abstract and interface
• abstract and final.

[pq]

It would make sense for, e.g., dartdoc to omit any reference to the constructor, similar to constructors of abstract interface or final classes.

fyi @srawlins

[matanlurey]

Thanks @pq!

[pq]

You bet @matanlurey. Thanks for the thoughtful report!