3 ms·

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

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.

mjw1007 4y ago
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.
- pietroalbini 4y ago
  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!
s_tec 4y ago
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.
steveklabnik 4y ago
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.
- deleted 4y ago
  [deleted]
andrewf 4y ago
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 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.
- steveklabnik 4y ago
  Editions are not frozen in time; the vast majority of new features land in all editions. Only the "breaking" changes aspect is frozen.

mjw1007 4y ago

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.

pietroalbini 4y ago
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!

s_tec 4y ago

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.

steveklabnik 4y ago

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.

deleted 4y ago
[deleted]

andrewf 4y ago

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 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.

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