reference

ket just because of this either. In contexts like safety critical/offline environments, the consequences of unexpected behavior can be dire and hard to fix in the moment (e.g. airplanes in flight). Liability becomes a real concern, and outside parties need a "contract" to be confident certain expectations or behaviors will be met in perpetuity. The reference doesn't offer that guarantee, and has understood itself to be a best-effort technical reference, despite attempts to increase its authoritativeness into a spec https://github.com/rust-lang/reference/issues/629 My opinion is that the spec is actually more needed for people inside the language than for people outside. Like the contractual element of a language spec fulfills a constitutional, if not judicial role, in the development process. However, I've learned requires a level of integrity that Rust can no longer hope to achieve.

tive compiler for Rust (https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...) Hope that helps dispel the confusion around the lack of spec or alternate implementation.

s more about this than I ever will).

e stability very strongly, and don't have the ability to document things with the guarantees we'd prefer. You might call it... not mature enough yet :) There's been a bunch of movement here, I'm excited to see it continue to develop! > Function/method calling convention. ... I’m told that newer versions of the compiler handle it just fine but the question still stands The objection here doesn't have to do with calling conventions, actually, this is about "two-phase borrowing," described in a series of blog posts ending here http://smallcultfollowing.com/babysteps/blog/2017/03/01/nest... I believe this will get even better with polonius https://nikomatsakis.github.io/rust-belt-rust-2019/ Regarding argument evaluation order, technically it is not yet documented https://github.com/rust-lang/reference/issues/248 but has been left-to-right for basically forever https://internals.rust-lang.org/t/rust-expression-order-of-e... and I actually thought that it was documented as such. I would expect this to shake out the exact same way as struct field destruction order, that is, something that's been one way for a long time and so we wouldn't change it even if maybe it's a good idea to. > Traits... the problem is not me being stupid but rather the lack of formal description on how it’s done and why what I want is so hard. Then I’d probably at least be able to realize how I should change my code to work around the limitations. Upcasting/downcasting is rarely used, and so has less love, generally, it's true. > First of all, bootstrapping process is laughably bad. So, Kostya acknowledges > Of course it’s a huge waste of resources for rather theoretical problem but it may prove beneficial for compiler design itself. Which is I think the way most feel about it. However, there is some desire to improve this, for other, related reasons. https://matklad.github.io/2020/09/12/rust-in-2021.html talks about some of them. > Then there’s LLVM dependency. While this stuff is all true, we wouldn't be where we are without it. Everything has upsides and downsides. > And finally there’s a thing related to the previous problem. Rust has poor support for assembly. He mentions asm; we're almost there! It took some time because it is not a simple problem. At the end of this, we'll have better support than C or C++ according to his metrics; these are not part of the language standard, so give his previous comments about maturity, I find this one a little weird, but it is what it is. :) > There’s also one problem with Rust std library that I should mention too. It’s useless for interfacing OS. Yes, the intention of the standard library is to be portable, so that's not really a goal. > But the proper solution would be to support at least OS-specific syscall() in std crate This may in fact be a good idea! I'm not sure how much use it would actually get.

a section on special Unicode productions. This section defines identifiers in terms of Unicode's XID_start and XID_continue, but this is referring to the unstable non_ascii_idents feature, not anything in the stable language. There is a footnote noting as such, and saying that the situation is expected to improve soon, but this feature gate has existed since before 1.0 and AFAIK no RFC has ever been written to describe this feature, so this footnote gives a false sense of optimism. Furthermore, as per the discussion at https://github.com/rust-lang/rust/issues/28979 , it's very unclear whether or not the stable form of this feature will end up using XID_start or XID_continue. My fix is https://github.com/rust-lang/rust/pull/50790. In the same section on Special Unicode Productions, it defines the non_null character class as any Unicode character but null, and then the non_eol character class as any non_null character except for newline. Below it then defines a grammar for line comments as two forward-slashes followed by zero or more non_eol characters. But this is incorrect, because Rust does allow null characters in comments: I don't expect that a code example will survive network transmission, but modify the following program by replacing $ with a null to see that it only prints "2", not "1\n2": fn main() { // test $ println!("1"); println!("2"); } I doubt that this is a bug in rustc, because Go, which like Rust also mandates UTF-8 source files, considers newline to be the only way to terminate a line comment and AFAIK has no issues with accepting nulls. We also allow other nonprinting characters in comments. This same error exists for the classes concerning what is valid in char and string literals. My fix is https://github.com/rust-lang/rust/pull/50791. Going back to the Notation page, the next paragraph has links to the sections on unary and binary operators. The section on the dereference operator has a typo: "variance" should be "variable". The section on the question mark operator has the typo "errornous". The operator table should have a footnote specifying that integer division rounds toward zero (as opposed to applying a floor function, e.g. http://mathworld.wolfram.com/IntegerDivision.html). (Given the existing footnotes specifying the behavior of the right-shift operator, I assume this is the proper place for this.) Further down, the section on type casts is incomplete; the coercion table misses that non-capturing closures can be cast to function pointers. The section on assignment expressions should note that assignment expressions evaluate to (). Fixes at https://github.com/rust-lang-nursery/reference/pull/337. The Notations page links to a section on tokens. The Characters and strings table has a column labeled "# sets" that uses notation like "0...", which should have a footnote for clarification. The section on Character escapes refers to the previously-defined term "7-bit character code" as an "8-bit code point escape". In the section on Byte and byte string literals, the grammar definitions for ASCII_FOR_CHAR and ASCII_FOR_STRING exclude forward slashes, when they should exclude backslashes. The section on invalid integer literals says that overflowing literals are invalid, but they're not (this one is arguably something that ought to be changed, and I've opened https://github.com/rust-lang/rfcs/pull/2438 to discuss changing it). The section on valid integer suffixes omits the new 128-bit types. Fixes at https://github.com/rust-lang-nursery/reference/pull/338 for these. That covers all pages reachable from the first two paragraphs of the reference and notes all the errors that are obvious to me in a single pass. I don't intend this as a disparagement of the documenters--language references are damn hard. There's surely plenty that I've overlooked. The degree of detail is overwhelming and the inherent authority of the word "reference" means that stakes are high. Compared to our other stellar docs the reference is notably lacking, and releasing it alongside them is an outlier from our usual standard of quality. Several large concepts are missing (such as, AFAICT, the type inference algorithm); the section on unsafety may even (if I'm properly interpreting the mood of the members of the unsafe code guidelines working group) be verging on misleadingly dangerous (suffice to say I think the Nomicon should be nightly-only as well (which is also not intended as a disparagement of Gankro's efforts)). The fact that people are still interpreting the reference so authoritatively suggests that more steps could be taken to reduce confusion. At the very least I think it should moved to nightly-only (and likewise remove its mention from www.rust-lang.org)... and maybe also add one of these: http://images.mentalfloss.com/sites/default/files/styles/ins... :) I apologize for the phrase "unprincipled dumping ground", it was a rash way of saying that the reference is developed in an ad-hoc way where sections are (mostly) added or improved without apparent overarching guidance or large-scale vision, hence all the missing pieces and parts that still date back to 1.0. I also apologize for suggesting that it ought to have been deleted; I still harbor a latent prejudice against the reference for all the years where it existed without anybody noticing that multiplication's precedence was specified as somewhere between addition and subtraction. :)