Re: [PATCH 0/8] rust: add preludes to all crates

[Paolo Bonzini <pbonzini@redhat.com>]

On Mon, Nov 17, 2025 at 9:03 AM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Mon, Nov 17, 2025 at 11:43 AM Paolo Bonzini <pbonzini@redhat.com> 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