I personally feel like this falls clearly into the soundness hole catagory and should be allowed to be removed in a breaking way. I understand the desire to avoid breaking changes, but soundness issues like this chip away at what "safety" in Rust really means.
I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Rust. Users of older versions of Rust can still use the removed function, but newer editions ban it.
This could be implemented as a reserved STD function list in the compiler if it must, since as you've mentioned we only have one STD lib atm.
I think it could be an edition thing though... just say Rust 2019 will not allow `Command::before_exec`. By turning on edition 2019 you've accepted the new brakages that it imposes on you, and this is one of them.
Never mind the fact that the function is still a symbol in the STD library.
I understand if this is too much complier magic, though it seems like the correct idea to me anyway.
Am I missing something?
P.S. symbol version pinning seems like a great idea, I've even dreamt of having exposed syntax for it, e.g. `Foo::<i32>::bar@v1.3.2(arg1, arg2)`.
It is not possible to have the standard library be different for different editions; it must be the same in all of them. There’s no #[cfg(edition=“”)] construct.
Can't there be a # [deprecate(untiledition=2018)] to solve this? The standard library contains all the old stuff but it becomes inaccessible in all editions after 2018.
I think I'd expect to see warnings about the existing safe method being deprecated for a while, then it's complete removal at the time of another edition of Rust. Users of older versions of Rust can still use the removed function, but newer editions ban it.
This could be implemented as a reserved STD function list in the compiler if it must, since as you've mentioned we only have one STD lib atm.