Hacker News Reader

Comment by masklinn | Hacker News Reader

Aside from the header issue, it doesn't allow for or support backwards-incompatible changes.

Because editions are opt-in (and library-level source metadata) the language itself can be modified in non-backwards-compatible ways.

So for instance a C++ with editions could make ctors `explicit` by default, or it could entirely change the automatic member generation (by removing it for instance). As long as the ABI and API remain compatible, that's fine.

View on HN

It’s probably worth noting that the backwards compatibility breaking changes I think only applies to the language and not the standard library. I’m unable to look up the details right now but I believe there’s a trait function defined in stdlib which is deprecated, supersede, but can’t be removed even as part of an Edition, or it would break older code.

That is correct, editions are mostly about language-level syntactic changes, the APIs have to be compatible between editions. The only place where that isn't the case is the standard prelude (the "builtins" you don't have to import).

The ability to replace the prelude does mean that you can imagine if somebody invents a much better thing than, say, Rust's iterators Rust 2050 can have a prelude that brings in std::better::Iterator instead of std::iter::Iterator and then most coders will end up using the new better iterators, just because that's the kind you get out of the box.

Anybody who literally refers to std::iter::Iterator gets the old ones of course as does any library code from prior editions, but the documentation could lead those few people in the right direction. And presumably std::better::Iterator politely implements std::iter::IntoIterator because why not.

I would be interested to understand if they're allowed to replace the macros. The standard macros aren't actually from the prelude, but instead if you aren't no_std you get all the standard macros anyway. Are they allowed to change those in a future edition? Or not?

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.

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.

Seems like it ought to new possible to rename std::iter::Iterator to std::iter::OldIterator, add std::iter::NewIterator, and then vary which iterator std::iter::Iterator points to based on edition.

Maybe that would be considered too confusing though.

Reply on news.ycombinator.com