Hello, I've come into a situation where the user implements some trait for some type "Inner", and then may use another (freely-implemented) "Outer" type (which uses the user's Inner impl).
The trait has two functions (a and b), but the user may really use only one of them (a).
The other function (b) has a default impl (which panics), so the user is not bothered with it when implementing (a).
Is it possible to confirm that this default method (b), which just panics, is never "actually called" at compile-time (rather than having a runtime panic)?
The example includes a situation where the Outer type defines the (b), so it's available for usage, and specializes (a) into panicking. Would it also be possible to confirm in compile-time that (b), from Outer's, is never "actually called"?
First off, AFAIK this trait will not even be usable at compile time, let alone the methods in it. The reason is that compile time function evaluation is not stable at this time.
Second, the design raises the little hairs on my neck, and the reason is the trait's "inner" method.
If the trait method is not meant to be usable by any random consumer, then it shouldn't be part of the trait.
The fact that the default method implementation panics is a really strong sign of this.
See it this way: traits should always be regarded as providing a public API, even when they're not actually accessible publicly (e.g. by defining the trait in a non-public module).
Thanks for your inputs, jjpe. I agree with your points and will approach differently. I won't comment on any of them because you're correct in my view.