Assuming preludes

Do you ever blindly assume there's a prelude? Do you ever add a new crate to Cargo.toml and then immediately add use <crate>::prelude::* to your source?

Is generally considered to be idiomatic to have a prelude, even if the crate is relatively small?

No.

I don't think there's an unconditional need for a prelude. It doesn't even depend on the size of the crate, but the complexity. A prelude helps the user avoid many deeply nested imports, while still preserving the author's right to structure the modules as ornately as necessary.

2 Likes

Literally never.

In general, I strongly dislike preludes. I use every name explicitly because I want to know what is in scope, and where it came from. The two exceptions I make are for the standard prelude (because in my mind those items are practically just part of the language), and for project-specific preludes (which only contain things I'm importing >80% of the time anyway)[1].

I can't recall ever seeing anyone upset that a crate didn't provide a prelude. But, then, I'm obviously quite biased. :slight_smile:


  1. And even then, I often end up removing them later on because they make the code harder to read when I come back after a break and no longer remember exactly what is in the prelude! ↩ī¸Ž

6 Likes

Ditto. Preludes make security audits challenging.

And they — or rather, glob imports, whether or not the module is called a prelude — make it hard to understand code someone else wrote, especially if there is more than one of them.

3 Likes