Conventionally, this idiom is known as an extension trait.
The general convention amongst the community is to name extension traits for type Foo as FooExt, though it’s not a hard rule (see e.g. itertools::Itertools).
The missing part of the puzzle for trait resolution in this article: a trait has to be “in scope” for it to be selected as a candidate for an associated function. If another crate or module implements a FooExt extension trait, then that trait has to be use-d at some enclosing scope in the code module in order for its augmented functions to be visible.
Good point about the importing via use. I’ve found that rustc is pretty nice about suggesting traits to import, though.
Going through a lot of this reminds me of dealing with Haskell typeclass coherence/consistency issues and I go wonder if Rust will ever end up going down this road (the classic example being not being able to have a “default” implementation for traits with more specific implementations down the road)
A few things to add:
FooasFooExt, though it’s not a hard rule (see e.g.itertools::Itertools).FooExtextension trait, then that trait has to beuse-d at some enclosing scope in the code module in order for its augmented functions to be visible.Oh, thank you for the term of art!
Good point about the importing via
use. I’ve found thatrustcis pretty nice about suggesting traits to import, though.Going through a lot of this reminds me of dealing with Haskell typeclass coherence/consistency issues and I go wonder if Rust will ever end up going down this road (the classic example being not being able to have a “default” implementation for traits with more specific implementations down the road)