You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issues with library private members in public interfaces is known. We have no current plans to change that.
This is a particularly useless case, where it might be reasonable to warn the user that the class can be implemented.
I'd recommend not making the class public, rather than introduce rules preventing you from extending the class.
We hope that adding the ability to prevent implementation or extension of classes explicitly (#2242) will allow you to disallow it in the cases where you want to, without the compiler having to figure out whether a use is safe or not.
Activity
srawlins commentedon Nov 23, 2022
One note: Extending
A
from within the library whereA
is declared can be valid.lrhn commentedon Nov 23, 2022
The issues with library private members in public interfaces is known. We have no current plans to change that.
This is a particularly useless case, where it might be reasonable to warn the user that the class can be implemented.
I'd recommend not making the class public, rather than introduce rules preventing you from extending the class.
We hope that adding the ability to prevent implementation or extension of classes explicitly (#2242) will allow you to disallow it in the cases where you want to, without the compiler having to figure out whether a use is safe or not.
AlexanderFarkas commentedon Nov 24, 2022
When you introduce
closed
modifier for classes, lint ruleno_non_closed_public_abstract_classes_with_private_abstract_members
will be awesome