[nicebyte]

a "language standard" is something i can use to hold implementation developers accountable. it doesn't matter if it's an actual international standard, or just a document on the internet. I want a dry, exhaustive and systematic description of the features and intended behaviors. Refer to the Vulkan spec (https://www.khronos.org/registry/vulkan/specs/1.2/html/) to get an example of what i consider a good specification.

The rust docs don't currently meet that bar. They're quite WIP, and I imagine someone hitting a particular edge case will not necessarily be well equipped to understand whether the behavior they're observing is intended, a bug in the implementation or something else entirely.

[mjw1007]

Yes.

There is a great deal of written information about Rust-the-language which exists only in compiler comments, RFCs, bug reports and internals.rust-lang.org threads (often slightly stale in all cases).

It's Rust's greatest weakness.

But "every time this comes up" the discussion somehow gets sidetracked into arguments about standardisation, even in cases (such as this thread) when it's clear that what the ranter cares about is accurate documentation.

[nyanpasu64]

a "language standard" is something i can use to hold implementation and library developers accountable. I want a dry, exhaustive and systematic description of what code is legal and illegal. Instead we have arguments over whether some unsafe code found in the wild is UB and will break once LLVM fixes noalias for real this time, not UB (eg. holding raw pointers into a Vec while the Vec moves without reallocating), compiles fine but may break in the future (eg. holding raw pointers into a Box while the Box moves), compiles fine but the Stacked Borrows rules forbid it but will eventually be changed to not forbid it (Pin). Instead of a firm contract between the compiler and the programmer, we have unsafe code guidelines which is the language team's best idea at the moment for what is legal or not.

Even though C++ code in the wild is filled with standard violations, I like having a standard explaining what rules exist, so developers can reason about them, and I can use them to tell other developers to change their code because their code is invalid. (In practice I don't know if violating strict aliasing through reinterpret_cast rather than bit_cast can lead to compilation errors, and sadly std::variant can miscompile due to broken aliasing optimizations in library code even with valid user code: https://www.reddit.com/r/cpp/comments/j7gn2d/stdvariant_is_b....) Currently, not all unsafe Rust can be classified as either valid (make sure the compiler doesn't break it) or invalid (change the code until it's valid), though there are some cases where unsafe Rust is clearly invalid.

Maybe it's a temporary state while the language team makes decisions based on how the unsafe library ecosystem progresses. Maybe the language team has no plans to put the language on a firm groundwork defining exactly what is legal or not, which I find uncomfortable (though maybe others feel more comfortable with it). In any case, there's not that much practical impact on the quality of code being written and binaries being produced, but it still hurts to see people building castles on uncertain foundations.

[Subsentient]

Yeah that's a whole nother can of worms for me with Rust, something that pisses me off a lot. By enforcing strict aliasing with no way to disable, Rust is making unsafe code intrinsically more unsafe, because you can't get predictable behavior. I'd rather it be called UB and work as intended anyways. But no, rustc devs in their infinite wisdom decided not to provide what is to me a core compiler flag.

[nyanpasu64]

> I'd rather it be called UB and work as intended anyways.

Personally I disagree. If you want to write freely aliasing code, I think it's better to use &UnsafeCell or &Cell or &RefCell, perhaps with an Arc (or my AliasPtr crate) instead of trying to convince rustc that &mut isn't exclusive.