Does "Accept Interfaces" break deprecation tooling?

Question

Deprecation

The supported way of marking functions as deprecated is something like this:

type MyStruct struct {
}

// MyFunc returns hello
// Deprecated: Use YourFunc
func (m MyStruct) MyFunc() string {
  return "hello"
}

Modern IDEs will highlight any usages of this function and linters might also raise warnings (I haven't personally checked this)

Accept interfaces. Return structs.

A popular best practise is "Accept interfaces. Return structs." - which tends to encourage SOLID design in software.

However, the following code - which follows this best practise - conceals the deprecation warning:

// 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()

}

Question

Is there a solution to this problem?

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.

Answer 1

That seems logical since the method of the interface has not been deprecated. Adding the Deprecated: line to the interface function might help in this case (didn't test, since VSCode doesn't do this yet).

// MyInterface specifies a single function that we require from a dependency
type MyInterface interface {
    // Deprecated: use YourFunc
    MyFunc() string
}

In this case, because the interface only has 1 function you should deprecated the whole thing. Which I know is supported by godoc/pkg.go.dev, take Queryer for example.

// MyInterface specifies a single function that we require from a dependency
// Deprecated: use YourInterface
type MyInterface interface {
    MyFunc() string
}