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...
8 Likes
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 
no_prelude module attribute?
#![no_implicit_prelude] already exists (and also see RFC 501 āConsistent no-prelude attributeā and the issues linked to it).
5 Likes
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.
6 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.