On Tue, Jan 18, 2022 at 1:07 PM Rowan Tommins <rowan.coll...@gmail.com> wrote:
> > Fair enough, that's a reasonable use case, thank you. I could quibble > and say that "self" or "static" would probably work in that particular > example, but I suspect that would just lead to an unproductive spiral of > example and counter-example. > > Not even a separate counter example actually. Static analysis, including in IDEs, will mis-type the return value as being the trait itself within the trait. So for instance, in my example I used the add() method from the trait in a separate method within the trait. If I return "self" or "static", my IDE will think that *within* the trait it is returning itself, even though traits can't be directly instantiated. (Or more accurately, it won't be able to understand what other types it may satisfy.) This is something I've had to do some real design gymnastics before to get around. I encountered this in a situation where I needed to check between a ComplexNumberInterface and a NumberInterface in the math library I maintain, since they behave differently for the same operations (which was an example of my motivation for operator overloads). Jordan
