Do you consider trait-to-extend as a anti-pattern about patterns HOT 2 CLOSED

Well, an "extension trait" is the most sane solution to extend foreign structs (e.g. ones from another crate that you have no control over) that I' aware of. So in this case I wouldn't consider this an anti-pattern.

For types in the same crate, it surely is questionable why you'd provide functionality for one specific type via a trait, imo. Of course, if you can, in principle, implement the trait to other types in a sensible way it's a whole different story. And this may include cases where the functionality is, in principle, still pinned on some struct.

For example, I'm currently working on a little thingy where I want to support accessing some struct Buffer both from multiple threads and a single thread through some struct Extender without needing to carry around the weight of a mutex in the latter case. So I ended up implementing a trait Accumulator for my actual target (e.g. struct Buffer), but also for Arc<Mutex<Buffer>>. So you could consider Accumulator an "extension trait", but there's still merit in having it this way rather than having implementing the functionality directly on Buffer.

from patterns.

If we think it is preferred solution, will it make sense to add to "pattern" section?

from patterns.