Rust extension traits, greppability and IDEs - Eli Bendersky's website

Extension Traits: Power with a Readability Cost

Rust's trait system is central to how the language handles polymorphism, both static (as bounds on generics) and dynamic (via trait objects). While traits themselves are well documented, the specific pattern of extension traits — adding methods to types you don't own — has notable implications for code exploration and maintenance that deserve closer scrutiny.

As RFC 0445 defines it, an extension trait is a programming pattern for adding methods to an existing type from outside the crate that defines that type. The mechanism itself is straightforward. Start with a trait defining a method:

trait Magic {
    fn magic_num(&self) -> usize;
}

You can implement that trait for your own custom types:

struct Foobar {
    name: String,
}

impl Magic for Foobar {
    fn magic_num(&self) -> usize {
        if self.name.is_empty() {
            2
        } else {
            33
        }
    }
}

The real value emerges when you implement it for types you don't control. For example, implementing Magic for a built-in type like bool:

impl Magic for bool {
    fn magic_num(&self) -> usize {
        if *self {
            3
        } else {
            54
        }
    }
}

This means you can write true.magic_num() and it compiles and runs. The same applies to types from the standard library:

impl<T> Magic for Vec<T> {
    fn magic_num(&self) -> usize {
        if self.is_empty() {
            10
        } else {
            5
        }
    }
}

Common Examples in the Ecosystem

This isn't an esoteric corner of the language. Prominent crates rely heavily on extension traits. serde, for example, defines serde::Serialize. After importing that trait and a concrete serializer, you can serialize any type that implements it without ever naming Serialize explicitly in your code:

let mut serializer = serde_json::Serializer::new(std::io::stdout());
185.serialize(&mut serializer).unwrap();

The import is mandatory even though the name never appears in the body; Rust requires explicit imports of traits to avoid method collisions between crates.

The byteorder crate demonstrates the same pattern for binary encoding. Importing its trait and enum gives vectors new methods directly:

use byteorder::{LittleEndian, WriteBytesExt};

// ...

let mut wv = vec![];
wv.write_u16::<LittleEndian>(259).unwrap();
wv.write_u16::<LittleEndian>(517).unwrap();

Here, write_u16 is defined in the WriteBytesExt trait and implemented for any type that implements Write — in this case, a Vec. The rayon library for parallel iteration takes this further, recommending a wildcard prelude import:

It is recommended that you import all of these traits at once by adding use rayon::prelude::* at the top of each module that uses Rayon methods.

With that single line, you get parallel iterators that work just like standard ones:

let exps = vec![2, 4, 6, 12, 24];
let pows_of_two: Vec<_> = exps.par_iter().map(|n| 2_u64.pow(*n)).collect();

Notice the par_iter call — a method that doesn't exist on Vec in the standard library.

The Greppability Problem

The functionality is useful, but the pattern fails what you could call the "greppability" test. Greppability refers to how easily you can understand a codebase using text search tools like grep, git grep, or ripgrep. Extension traits often defeat textual exploration.

Consider encountering this line while browsing an unfamiliar project:

let mut wv = vec![];
wv.write_u16::<LittleEndian>(259).unwrap();

Your first thought is that Vec has some obscure method you've never seen. A search of the documentation says no. A grep across the codebase finds nothing. Only after inspecting each import do you notice:

use byteorder::{LittleEndian, WriteBytesExt};

Recognizing LittleEndian might lead you to the byteorder crate's documentation, where the method is defined. With rayon, it's harder. A wildcard like use rayon::prelude::* contains no textual hint linking it to par_iter unless you already know the crate.

Of course, searching online for the symbol usually resolves the ambiguity. And if you work in an IDE that resolves symbols through a language server, none of this is an issue.

Language Servers Versus Text Search

Modern editors, particularly Visual Studio Code with language servers like RLS for Rust or gopls for Go, understand code at the level of the compiler front-end. They maintain type-checked abstract syntax trees, so hovering over any symbol reveals its origin and documentation.

This makes the lack of greppability seem like an outdated concern. Perhaps working with Rust without a sophisticated IDE is simply impractical today. Still, there is real value in being able to understand a project with nothing but grep and official documentation.

This evolution isn't unique to Rust — exploring a Java enterprise codebase effectively requires an IDE, and that has been true for a long time. What's notable is that systems languages, once the domain of plain editors and command-line tools, are moving in the same direction. Go, by design, avoids these issues by using explicit package.Symbol syntax and never injecting names implicitly.

The discomfort isn't about the extension trait mechanism itself — it's about the trade-off. Every layer of indirection that an IDE hides is a layer that textual search tools cannot penetrate. Whether that's a price worth paying is a judgment each developer will have to make for their own workflow.