Hacker News Reader

Comment by 2bitencryption | Hacker News Reader

one thing I don't fully get-

this specification is written based on the current behavior of rustc. The page even says that the specification will be updated as rustc is updated:

> If there is a mismatch between what the FLS says and how the compiler behaves, the specification will be updated.

So, rustc is not written to this specification, but rather this specification is written to match rustc.

So if I am writing my own compiler, using this specification, do I have to worry about the specification changing, if suddenly a regression is introduced to rustc, and the specification is updated to cover the regression?

mostly I don't understand. I'm sure someone could explain this and it will make sense to me.

View on HN

The same thing occurs with Web standards.

If some old IE version did things a certain way, even the most modern browser will want to do things in a similar way to remain compatible. Therefore, the standards bodies will try to reverse-engineer the existing behaviors and then create standards based on those. That way, modern code can simply follow the spec and remain compatible.

The HTML5 parsing algorithm is an example of this. Old browsers tried to "fix" broken HTML by guessing where things like missing closing tags were supposed to go. The HTML 4 specification never described this logic, yet it was there in the wild. The new HTML 5 specification made a point of reverse-engineering the repair algorithms and actually documenting them, so now everyone can be compatible going forward, both with each other and with legacy. Just follow the spec.

The specification is versioned. So your compiler would need to be updated to work with the new specification, both with new features and with new bugfixes.

If you're writing your own compiler, I don't think the Ferrocene specification will help you.

It's basically an old version of the Rust Reference written out in a more bureaucratic manner.

(I see a little new material, such as the Name Resolution subsection, but even that is incomplete and I think wrong.)

Neither of these things is anywhere near close enough to being complete and correct to implement a compiler against.

Note that this is just a first draft of the ferrocene spec, we aim to get it to a finished state by the end of the year!

Presumably they'd freeze snapshots/versions of the behavior at various points in time, similar to https://doc.rust-lang.org/edition-guide/editions/index.html

An analogy from the C++ world: In late 2016, there was an evolving C++17 specification, and the latest versions of gcc and clang were starting to implement C++17 behaviors. But you could read the C++14 specification to understand "this is what everyone agreed on in 2014", and invoke your compiler with the -std=c++14 flag to get that behavior. If you already had older software written against the C++11 spec, invoke your compiler with -std=c++11.

Editions are not frozen in time; the vast majority of new features land in all editions. Only the "breaking" changes aspect is frozen.

Reply on news.ycombinator.com