@keep94 this seems ok, but also forces the issue. I'm not sure if there's a correct or idiomatic option in Go: should we go with this PR or #115?

Is the description of this PR correct?

Make Sender so that it can't be implemented externally.

I thought we were concerned about making breaking changes by adding new public methods to the Sender. If that's the case, what if we instead wrote a test for each of our interfaces and use reflection to assert that only the desired methods are included? If someone adds a new method to an interface in the future, a unit test will fail to alert them that it would be a breaking change.

@oppegard I may have been unclear in my description of this PR. It is fine if we or someone else adds methods to the Sender interface in the future. I anticipate we will need to do that sometime in the future. This PR will allow us to safely add methods to the Sender interface as non breaking changes going forward. What we don't want is for someone outside of our organization to write their own concrete type that implements Sender and then pass their custom concrete type to a function that accepts a Sender interface. If they are successful at doing that then as soon as we add any new methods to the Sender interface we would break that person's code so that it doesn't compile. That person would have to fix their code by adding implementations of any new method(s) we added to the Sender interface in their concrete type. This would be a breaking change on our end. To avoid this type of scenario in GO, it is idiomatic to add private methods to the interface to keep external parties from ever writing a successful implementation of it. A good example of this is the Type interface in the reflect package of Go.

As far as whether this PR or PR #115 is better I am indifferent. #115 would allow us to add examples for individual methods of sender, but #116 is a more friendly breaking change.