On Mon, Nov 17, 2025 at 9:03 AM Marc-André Lureau <[email protected]> wrote: > > Hi > > On Mon, Nov 17, 2025 at 11:43 AM Paolo Bonzini <[email protected]> wrote: > > > > This series adds a prelude module to all crates, so that > > it becomes possible to import from each crate with either > > of the following > > > > use XYZ::prelude::*; > > use XYZ::{self, prelude::*}; > > > > The latter is used for items that have a "too common" > > name to be put in the prelude: util::Error, util::Result, > > migration::Infallible. > > In my experience, "preludes" are not so ubiquitous (except the std > library). The use of wildcard imports is not encouraged, and may > result in conflicts.
Yes, I agree with this. On the other hand, we already have lists of imports that are two-three lines long and I'm afraid that people would prefer to just import migration::* for example. While we can block them with -Dclippy::wildcard_imports, the problem is real. So I was a bit undecided and went looking for examples of crates that do have a prelude. I first noticed that bevy has a similar system, with each of its crates providing a prelude. IMO QEMU is a similar case to bevy, where most of the code will use structs from the QEMU crates more than std, so it makes sense to have them. Futures and Tokio also have a prelude, and they also fit the idea of crates that provide a programming environment. Preludes let you import libraries with a level of detail similar to C includes. For simple library crates that offer two-three types it's not necessary to have one, but as the complexity and number of crates increase, they provide more clarity. Another thing to notice is that the QOM bindings work a lot with extension traits implemented on all types. There should be no need for users to know the difference between DeviceState, DeviceMethods and DeviceClassMethods. Preludes help with that. > Also, it's often subjective what you put there or not. Right - for now I just defined what should *never* be in a prelude: the rule was simply "do not include anything that can conflict with std". This should not be that bad, otherwise we'd have similar problems with C includes as mentioned above. Another thing that should not be in the preludes without extremely good reasons is enum variants; Ok/Err and Some/None are the only exceptions in the standard library prelude, and they should probably remain the only ones. Paolo
