Hacker News new | ask | show | jobs
by stormbrew 1702 days ago
Personally I'd kinda like it if preludes were decoupled from editions in some way. Like, fine to have a default per-edition but there are times I would really like to have a prelude without all the `impl<T> X for T`s included.

You can kinda do this now with `#[no_implicit_prelude]` I think but it has somewhat odd semantics. It applies to all submodules, unlike most attributes, and then if you define your own prelude you need to use it in every submodule because they won't all have their own.

If it's gonna have global effect I think it'd be better if it was:

    #[prelude]
    mod my_prelude {
        use std::whatever::*;
    }
and then my_prelude would be included in all submodules by default.
1 comments

There was a proposal for that, but it wasn't accepted https://github.com/rust-lang/rfcs/pull/890
Hm. Not really fond of the way that RFC was closed tbh. I feel like far more dubious suggestions sit open for ages and the main argument against this one is that it had narrow use cases but was otherwise uncontroversial. Like, there's a fine line between a feature request is quiet because no one really wants it vs. because it's just kind of an easy small win that's not even worth bikeshedding.

Meanwhile, the thing that is in the language is.. weirder and arguably worse.

If you feel like it, maybe open a thread on internals.rust-lang.org? This issue can still be debated..

Also, it was closed in 2015; it was a different time back then. I don't think that RFCs from 2015 should be kept open just because. Arguably, Rust shouldn't have 88 RFCs open (as of now), either.