Note: Box
magic wrt. moving deref is a lot more complicated than simple DerefMove
.
For core
, I would strongly caution against allowing it's implementation in stable rust. core
, and many of it's components, necessarily interacts with internal implementation details of the rust compiler. By exposing these stably, they are fixed, and do not provide variation in those implementation details. Control over the precise assembly would require control over these implementation details (which comes at a cost of portability, including portability to different versions of the same implementation).
And, as an implementor, trying to (eventually) have parity with rustc stable, I very much thank them for that limitation. I'd prefer that crater runs, when I have a compiler that can do those, not fail because crates are opting out of stability on the version of the compiler that I should be able to rely upon implementing the core language, and only making the core language available.
I can list 5 more features in the C++ Standard Library that are language critical, and at least dozen that are magic and cannot be implemented in user code. For example, good luck implementing std::bit_cast
correctly without some semblance of knowledge about the compiler (Hint: It cannot be done in the general case). While C is much less attached to the standard library, <stdarg.h>
and <setjmp.h>
would like to have a word with you.
Not to sound like a broken record, but I consider that a good thing. Stable Rust is also portable rust. Not only would opting into the unstable lang items and builtins be unstable, they are inherently non-portable.
In my (very WIP) implementation, lccc, some things that are lang items in rustc are not (Box
, ManuallyDrop
, and UnsafeCell
are examples that come to mind), and there are additional lang items, such as one for an unstable DerefMove
and DerefPlace
(which together are used to implement Box
moving deref).
I would like to eventually have the ability to test lccc against stable rustc, and this is fundamentally incompatible with stable rustc allowing access to unstable implementation details to any crate that wants them.
As someone who builds C++ software using trunk clang (like, at most a week old off main, trunk clang), I absolutely disagree with the statement. Also, for the reasons I set forth above, I think it's a good thing that stable rustc be stable rust only.