Hacker News Reader

Comment by steveklabnik | Hacker News Reader

> Why couldn't the Rust team maintain a spec and keep it up to date by changing it in the same pull request that changes a language feature in the compiler? This seems like mostly a matter of discipline.

It's not that, it's that we take the idea of a spec very seriously. We want to have a spec that's extremely solid, and so there's a lot of foundational work that needs to be done first. That work has been ongoing. Not all specs are created equal, and good ones take a lot of time.

For comparison, C was created in 1972, and the first specification happened in 1989.

View on HN

Okay, but this seems like letting the perfect get in the way of the good? A maintained, readable, informal spec should be quite useful as a starting point for writing a more formal spec later.

It need not be definitive. It would be quite reasonable to point out areas that aren't nailed down yet - this is also useful for the reader.

That's what the reference is, and it's there for exactly that purpose.

What do you want out of an informal spec that isn't provided by "The Rust Reference"[1]?

[1] https://doc.rust-lang.org/reference/index.html

It's useful but I'd like to see a bit more top-level completeness. Every feature should be listed and have at least a cursory description, even if it's not entirely nailed down.

(Maybe it already is like that, but the disclaimers say it's not.)

The vast, vast majority does, but there may be some missing bits. Printed out, it's about 170 sheets of paper, so there's a lot there.

Borrow checking rules.

I don't know what the current state of affairs is, but this is something they have rightly delayed specing. The original borrow checking rules were quite byzantine compared to what we have today.

I don't know if there is active work going towards making them more relaxed (NLL landed I believe). However, a ton of work has happened to get them out of the way as much as possible.

Reply on news.ycombinator.com