title: Does "Accept Interfaces" break deprecation tooling?
body: <h2>Deprecation</h2>
  <p>The supported way of marking functions as deprecated is something like this:</p>
  <pre><code>type MyStruct struct {
  }
  
  // MyFunc returns hello
  // Deprecated: Use YourFunc
  func (m MyStruct) MyFunc() string {
    return &quot;hello&quot;
  }
  </code></pre>
  <p>Modern IDEs will highlight any usages of this function and linters might also raise warnings (I haven't personally checked this)</p>
  <p><a href="https://i.stack.imgur.com/x24Ib.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/x24Ib.png" alt="Showing the IDE highlight" /></a></p>
  <h2>Accept interfaces. Return structs.</h2>
  <p>A popular best practise is &quot;Accept interfaces. Return structs.&quot; - which tends to encourage SOLID design in software.</p>
  <p>However, the following code - which follows this best practise - conceals the deprecation warning:</p>
  <pre><code>
  // MyInterface specifies a single function that we require from a dependency
  type MyInterface interface {
      MyFunc() string
  }
  
  func main() {
  
      var v MyInterface
      v = MyStruct{}
      v.MyFunc()
  
  }
  </code></pre>
  <p><a href="https://i.stack.imgur.com/3ahZ5.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/3ahZ5.png" alt="Showing the lack of IDE highlighting" /></a></p>
  <h2>Question</h2>
  <p>Is there a solution to this problem?</p>
  <p>If I were, for example, a library maintainer: how can I ensure that my deprecation warnings are seen by users of the library who are also following best practises and defining their own dependency interfaces.</p>