It's the people that matter

Summary

Over the past two years, I've been involved with designing and implementing a new feature of rustc, called "externally implementable items". This is not a finished feature, though if you'd like you can try it on nightly already! This is the story of how externally implementable items were invented, implemented, and how some day they might be stabilized. I'm sure that is interesting to some of those who read this. That's not the main thing this blog post is about, though. Instead, I'm using it as an example, to show you how the Rust project operates. To show how many people are involved with a change, how they learn from each other, how I've learned so much from them myself. An example of how important social interaction is to open source. Much more than writing the code itself. This is a written-out version of a talk I gave at Rust in Paris 2026. The problem This story starts, almost two years ago, in the days after RustNL 2024. An RFC was opened by m-ou-se called Externally Implementable Functions, which was actively being discussed. The idea is as follows: In Rust, the ordering of modules doesn’t matter. As long as a function is visible enough (using pub qualifiers), any function can call any other function, regardless of definition order or location in the module tree. Though it’s probably not a great idea to call into this code, the following code does compiles in rust: That’s not the way that, for example, C works. In C, the global scope is not order-independent, and declarations are processed top-top-bottom. That means that you can only call a function after it’s declared. The way to work around this is by using what’s called a forward declaration: you can declare the type of a function first, without giving a definition. Then, other functions can use the declaration as a promise that a definition of a certain type will exist somewhere, and finally the definition can be given satisfying the declaration. In C, you’d have to write the following to achieve someth...