Method must be called

[subzero911]

Describe the rule you'd like to see implemented
Add an annotation for method that must be called at least once from somewhere and linter warning if it's not the case.

Examples
If I do not close a StreamSink, linter warns:

If I close it in dispose() but do not call _bloc.dispose() from my StatefulWidget's dispose(), linter doesn't notice it.

Thus we easily can have memory leaks and never know about it. That's why I propose such a rule.

[PlugFox]

void main() {
  final A a = A();
  // ...
}

class A extends Sink<int> {
  @override
  void add(int data) {
    
  }

  @override
  void close() {
    
  }
}

[subzero911]

Not exactly what I wanted to.
Sink forces me to implement add() method. I don't need add(), because I do not add anything.
I need something like Closeable / Disposable.

[pq]

Without global flow analysis a lint like this would be hard to enforce. (Note the various short-comings in close_sinks...) That said, I love the idea of generalizing so we should discuss.

See also: dart-archive/linter#2114

/fyi @bwilkerson

[subzero911]

I agree that it apparently leads to the slow global analysis.
What about adding a Closable or Disposable interface with the only void dispose() method, with corresponding lint You have a Disposable that you never dispose?

[bwilkerson]

Unfortunately, that would also require a global analysis. The only performant checks we can make while you're typing are those that are local to the code being edited. That means that we can check, for example, that an object created in a method and not passed out of that method is also disposed in the same method. But as soon as a reference to the object escapes the method then we can't check to see whether it's disposed elsewhere so we can't know whether it's a problem if it isn't disposed in the same method.

[subzero911]

So, for my case I see two ways:

• To extend/implement Sink and leave add() empty or to throw an Exception('This class is not meant to add anything') in add method.
• Not to implement Sink and try not to forget that I need to close it (in Provider dispose slot or in Stateful dispose method)

[bwilkerson]

I don't understand your requirements, so I'm probably missing something, but it seems like the two options are orthogonal. If the goal is to disallow code from calling add, then the first would presumably work. (Although I might choose to wrap the underlying sink because it isn't clear that you can control which subclass of Sink is created. You could even, potentially, make it an object that doesn't implement Sink and then you would have more control over the API it supports.)

If your goal is to be able to detect at analysis time the error of not closing the sink, then I don't know of any solution for that. The best approach I'm aware of is to follow some convention(s) that make it very hard to forget to close it (such as always closing it in the same method in which it is created).

[subzero911]

My goal is to have a close_sinks warning but not to implement add() method or to prevent calling it (just came up with workaround: mark add() method with @deprecated, so it will appear in Intellisense as striked out)