The problem that we are concerned about is more about tooling. If someone has (say) a build.rs script that relies on -Z plugins to do "something or other", and we change some details of this option, and then your library doesn't build any more -- that is still going to be frustrating. Similarly if you are using something in your personal toolchain.
Yes, I agree that's a problem. I like that all the "unstable" options are behind -Z and even OK with it printing a loud message every time you use them. I'd even be OK with requiring a -Z I-insertnamehere-being-of-sound-mind-understand-that-this-could-break-at-any-time-in-any-future-version option to make them available.
(I've talked at length about my problems with build.rs elsewhere, but it would be a very bad idea for build.rs to ever directly invoke rustc in any case.)
But by disabling them altogether, means that when options like -Zremap-path-prefix-from/to appear in a stable build, I won't be able to experiment to see if they work as I'd like when they are finally stabilized. I'd need to have a whole separate rustc version which is a lot more effort to start with which means the threshold for doing the experiment at all is a lot higher (which means less likely to happen), and changes a lot of other things as well (like the accepted language, which may in turn require code changes).
Which -Z features do you use for debugging? Is there a middle-ground where we can stabilize some heavily-used flags while still continuing with our plans to lockdown the compiler interface?
The options I've been playing with lately are -Zsanitizer= and I'd like to play with -Zremap-path-prefix-from/to once its in a stable build. Once I've deployed a new stable toolchain into our infra (just landed 1.17), if I have a spare moment I like to play with experimental features to see how I can make use of them. This is typically local changes to various bits of scripts and tools, which makes it all fairly low effort and low friction, which goes away if I have to include "use different compiler" in the mix.
(If anything, it would be more useful for me if rustbuild had a guaranteed-stable interface so that my local build scripts "just work" from version to version without changes (to be fair, it isn't too bad aside from some missing features).)
rustc should certainly have a guaranteed-stable set of functionality. But I don't see any value in making rustc have only a stable interface.
I'd also happily concede:
- the stable compiler shouldn't have any options which changes the language it compiles, and
- tools like cargo and/or crates.io should reject build specs that include -Z options