Removing/changing the prelude?

If big, backwards-compatibility breaking changes are on the table anyway, is it too late to ask for a removal of the prelude? Having to import everything, including std types would make code clearer and no_std environments easier to understand imho. Or is that idea silly?

1 Like

I'm personally quite opposed to such a change and think that it would make many common tasks pretty unergonomic. If anything, I think we should have a bigger prelude which includes things like Arc and Rc...


Overly aggressive solution: custom preludes! Allow specifying a module that is implicitly glob imported the way that std::prelude::v1 is today.

Upsides: domain specific preludes.
Downsides: differing preludes.

Of course, it's not too difficult to make your own prelude module and import that at the top of every file, and that's explicit. So maybe the solution is to fix the #[no_implicit_prelude]/#[no_prelude] situation.

Custom preludes due to @aturon seem like a nice idea to me (which can be done backwards compatibly afaikā€¦). But I think custom preludes can be combined with a more expansive std prelude :slight_smile:

no_prelude module attribute?

#![no_implicit_prelude] already exists (and also see RFC 501 ā€œConsistent no-prelude attributeā€ and the issues linked to it).


Regardless of whether or not it is a good idea, I do think it is too late to add something as dramatic as removing the prelude to our list of considerations for Rust 2018.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.