At last week’s meeting, we accepted an RFC that limits the ability to create trait objects: you would only be able to do so for traits where all of the methods are usable on a trait object.
That means, in particular, none of the methods can use generics or mention Self (except in receiver position).
We are having some second thoughts about this RFC, and want to gather more community feedback before moving forward.
The motivations for this change were given in the RFC. Part of the idea is that, when you’re designing a trait meant to be used as a trait object, you generally would not want to have any methods that are not usable via the trait object; these methods should live on a separate trait (the thinking goes).
In std, the main places this comes up – Iterator, Reader, and Writer – all follow a pattern where there are a small number of required methods, and then a large number of adapter methods with default implementations, some of which are not usable by trait objects. These traits could be split up into the required part and the adapters, with the latter providing a blanket impl usable by trait objects. So in these cases, following the new rule leads to a more powerful (albeit somewhat more complex and harder to document) design.
However, we are not confident that this pattern covers all use cases in practice.
So, Rust community: do you ever use trait objects for traits that provide methods with generics/Self, where those methods do not have defaults? Or where those methods couldn’t or shouldn’t be broken into separate traits? Tell us about it!