4 ms·

At this stage I'd settle for an informal language description, as long as it was a serious attempt to be basically complete and correct. It's nearly four years

At this stage I'd settle for an informal language description, as long as it was a serious attempt to be basically complete and correct. It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. It's surprising that a project which generally holds itself to high engineering standards is so sloppy in this one area.

kibwen 8y ago
> It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. I'm curious what standard this is holding Rust to; C was 17 years old when a comprehensive reference emerged, and C++ was 13 years old for the same. If Rust manages to have a reference by 2030 (and I certainly hope it does) then it will be on track.
- mjw1007 8y ago
  I think Go and Swift are natural languages to compare Rust to in this respect. Both of them seem to be doing a much better job of reference-level documentation. In other circumstances the Rust people generally aim for higher standards than "no worse than C or C++", let alone "no worse than C or C++ in the 1980s". (I mean, you don't see Rust people saying "It took 30 years for C++ to get any form of type inference, so as long as we have something by 2040 we'll be on track.)
steveklabnik 8y ago
I wrote a comment about this over here: https://news.ycombinator.com/item?id=19483241 https://news.ycombinator.com/item?id=19483241 One of the goals of this year's roadmap is to significantly improve the reference, by the way.
oconnor663 8y ago
A complete language description would need answers to all of the questions in, for example, this blog post: http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsafe-code-and-shared-references/ http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...
- mjw1007 8y ago
  (That's about the underlying pointer-aliasing model visible to unsafe code; the sort of questions that come up with C's "restrict".) I don't think coming up with answers to those questions need have blocked writing that part of the reference manual. One alternative would be to document what aliasing guarantees rustc currently does and doesn't pass down to LLVM, along with what (if any) promises Rust is making about which things that therefore currently have defined behaviour at the LLVM level will also do so in the final language model. The point is that the current reference manual should document the compiler-writers' current understanding of what is allowed.

kibwen 8y ago

> It's nearly four years since Rust 1.0 and the reference manual is still calling itself a best-effort document. I'm curious what standard this is holding Rust to; C was 17 years old when a comprehensive reference emerged, and C++ was 13 years old for the same. If Rust manages to have a reference by 2030 (and I certainly hope it does) then it will be on track.

mjw1007 8y ago
I think Go and Swift are natural languages to compare Rust to in this respect. Both of them seem to be doing a much better job of reference-level documentation. In other circumstances the Rust people generally aim for higher standards than "no worse than C or C++", let alone "no worse than C or C++ in the 1980s". (I mean, you don't see Rust people saying "It took 30 years for C++ to get any form of type inference, so as long as we have something by 2040 we'll be on track.)

steveklabnik 8y ago

I wrote a comment about this over here: https://news.ycombinator.com/item?id=19483241 https://news.ycombinator.com/item?id=19483241 One of the goals of this year's roadmap is to significantly improve the reference, by the way.

oconnor663 8y ago

A complete language description would need answers to all of the questions in, for example, this blog post: http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsafe-code-and-shared-references/ http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsa...

mjw1007 8y ago
(That's about the underlying pointer-aliasing model visible to unsafe code; the sort of questions that come up with C's "restrict".) I don't think coming up with answers to those questions need have blocked writing that part of the reference manual. One alternative would be to document what aliasing guarantees rustc currently does and doesn't pass down to LLVM, along with what (if any) promises Rust is making about which things that therefore currently have defined behaviour at the LLVM level will also do so in the final language model. The point is that the current reference manual should document the compiler-writers' current understanding of what is allowed.