Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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++.

 help



> (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.


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.

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: