could you support @noExtends and @noImplements for abstract class

[Silentdoer]

such as
class Base is an abstract class, I just want people to extends not implements, so I can use @noImplements(annotation in meta.dart):

@noImplements
abstract class Base {
...
}

if people use with class Child implements Base {...} will get a warning by analyzer

[lrhn]

This sounds like a request for "interface-less classes". We have other such requests in the language repository, and it might be part of any attempt to make sealed classes (it being a kind of "partially sealed").

It's definitely possible to add this to the analyzer as an annotation only.
There should be no need for @implements since you can prevent extends by not having any public generative constructor.

(I'd probably make it @extendOnly or @noImplements, to signal that it's a restriction. Also avoids any reserved word conflict. A class with @extends @implements looks like it should be able to do both, but if it really prohibits both, then it's confusing.)

[Silentdoer]

This sounds like a request for "interface-less classes". We have other such requests in the language repository, and it might be part of any attempt to make sealed classes (it being a kind of "partially sealed").

It's definitely possible to add this to the analyzer as an annotation only.
There should be no need for @implements since you can prevent extends by not having any public generative constructor.

(I'd probably make it @extendOnly or @noImplements, to signal that it's a restriction. Also avoids any reserved word conflict. A class with @extends @implements looks like it should be able to do both, but if it really prohibits both, then it's confusing.)

yes, it's my bad, @extends and @implements should be rename to @noImplements and @noExtends like you said.

[bparrishMines]

This would also be beneficial to federated plugins. Each platform implements a shared platform interface and we are programmatically checking that any class is extended and not implemented. But, there are still situations where a platform implementation can accidentally get around this. An analyzer warning would be easier to work with.

cc @stuartmorgan @pq

[pq]

/fyi @natebosch @munificent @jakemac53 @leafpetersen

[pq]

See also @lrhn's proposal: dart-lang/language#704

[jellynoone]

Also an added benefit with being able to force a client extending your class rather than implementing it is that you are also able to maintain some internal assertions.

For instance, defining a PositiveDuration class which essentially extends Duration and adds an assertion in the constructor so that the duration is indeed positive. (Of course even extending it you could break that assumption but in that case it would really be intentional.)

[srawlins]

These have all been implemented in the language.