3 ms·
I think that's a fair criticism of documentation of the language itself, for which there is no real documentation - while std/core is extensively documented and
by duped 4y ago
I think that's a fair criticism of documentation of the language itself, for which there is no real documentation - while std/core is extensively documented and it is quite good, syntax/semantics of Rust are not outside of the Book, various RFCs and discussion related to them, and various online sources.
But that's not what a language specification looks like. You will rarely turn to the ISO spec of C or C++ to learn something about the language unless you are trying to build a greenfield compiler. And while a lot of people want a second implementation of Rust for technical reasons, it's not as compelling as improving language documentation.
For example language documentation would look like: the `for x in y {}` syntax is called a "for" loop, which iterates over the expression `y` by calling the `next` method until it returns `None`. (this is bad, but you get the idea)
Language specification would be something like `for x in y { body }` is equivalent to
let y = y.into_iter();
loop {
match y.next() {
Some(x) => { body },
None => break;
}
}
While that language might be useful for some users, it's primarily useful for compiler developers. And since there is only one compiler, a spec to that detail is not compelling.
- cyber_kinetist 4y agoA counterpoint: I often found cppreference.com very useful when ironing out parts of C++ that I’m not sure about. (Yeah it’s not the full spec, but it’s at least a concise version of it made to be understandable for mortals.) Although the language has many cases of undefined behavior, at least they are clearly written down. Sucks to figure out how these rules all interact with each other though. Meanwhile, for unsafe Rust, if you look at the Rust Reference Book, there is a single page that lists the possible situations for undefined behavior, with an added warning message: “Warning: The following list is not exhaustive. There is no formal model of Rust's semantics for what is and is not allowed in unsafe code, so there may be more behavior considered unsafe. The following list is just what we know for sure is undefined behavior. Please read the Rustonomicon before writing unsafe code.” Then when I look at the Rustonomicon, it says: “Warning: This book is incomplete. Documenting everything and rewriting outdated parts take a while. See the issue tracker to check what's missing/outdated, and if there are any mistakes or ideas that haven't been reported, feel free to open a new issue there.” So maybe that should be more prioritized if Rust really wants to get the reputation of a safe, stable language. (Safe Rust is good, but Unsafe is where the real devils are all hidden…)
- duped 4y agoPart of that can be chalked up to the fact that specifying its behavior would limit it, and everyone who has delved deep into unsafe is familiar with how hazardous it is (unsafe rust is more unsafe than plain C or C++). I think debate is required before documentation.