[bulbar]

I don't follow Rust closely, but I somehow love that they just did it. I like C++, but it would be much less confusing if the committee dared to change the language or std from time to time. Instead, they only ever extend (with super rare outliers).

[pjmlp]

For better or worse, that is one reason why many of us still reach out to C++.

Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.

[ameliaquining]

Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks.

Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as true of C++.

[steveklabnik]

> (I don't know if they've considered adding it)

The paper you want to look up is “epochs” (the OG name for editions) but there were questions that never got resolved, and so the proposals are dead for now at least.

[pjmlp]

Editions for the time being don't cover all language evolution scenarios, e.g. breaking changes on the standard library, and having incompatible crates on the same build talking to each other.

[ameliaquining]

Is anybody contemplating nontrivial breaking changes to the standard library? When env::set_var and env::remove_var were marked unsafe, that was done across an edition boundary even though it's unsound to leave them as-is in older editions.

Do you have a particular scenario in mind for incompatible crates? This doesn't seem like a language evolution problem.