I feel that we could treat most complaints with the built-in prelude by allowing crate-wide imports. You’d declare these in your main.rs/lib.rs only and they’d be equivalent to being in the built-in prelude.
Forbidding collisions with the built-in prelude will avoid surprising single-file editors. Also forbidding use of privacy stuff before a use(crate) it as it wouldn’t apply.
As an alternative to rfc-890 I suppose it has similar drawbacks, but to me the syntax is lighter as it’s close to pub(crate). Forbidding collision with the std prelude also avoids a bunch of issues.
I read the comments on that rfc and I’m not currently convinced my version would be bad. Please help
The biggest advantage of “custom preludes” over ad-hoc use(crate) is only having one known location to look for for these implicitly-in-scope names. Restricting use(crate) to only be used at the root is surprising itself, as code in lib.rs cannot be indiscriminately moved to a different module (which was a part of the motivator for the edition changes to paths).
That said, the reason said proposal is a hard sell is that it’s not too hard to write use crate::prelude::* or even use crate::* in modules that want to bring common names into scope to work with, and that gives more local information about the presence of names.