4 ms·

But no-one writes code against the standard. We all write code against the reality of the compiler(s) we use. If there's a compiler bug, you either use a differ

But no-one writes code against the standard. We all write code against the reality of the compiler(s) we use. If there's a compiler bug, you either use a different version, a different vendor, or we side step the code triggering the issue. The spec only tells you that the vendor might fix this in the future.

_gabe_ 3y ago
This is definitely not true. Whenever I have a question about a C++ language feature I typically go here first[0], and then if I’m looking for compiler specific info I go to the applicable compiler docs second. Likewise, for Java I go here[1]. For JavaScript I typically reference Mozilla since those docs are usually well written, but they reference the spec where applicable and I dig deeper if needed[2]. Now, none of these links are the specifications for the languages listed, but they all copiously link to the specification where applicable. In rare situations, I have gone directly to the specification. That’s usually if I’m trying to parse a subset of the language or understand an obscure language feature. I would argue no one writes code against a compiler. Sure we all validate our code with a compiler, but a compiler does not tell you how the language works or interacts with itself. I write my code and look for answers to my questions in the specification for my respective languages, and I suspect most programmers do as well. [0]: https://en.cppreference.com/w/ https://en.cppreference.com/w/ [1]: https://docs.oracle.com/javase/specs/index.html https://docs.oracle.com/javase/specs/index.html [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript
- estebank 3y ago
  If the compiler you use and the spec of your language disagree, what do you do? The Project is working on a specification. The Foundation hired someone for it. A Rust spec done purely on paper ahead of time would be the contents of the accepted RFCs. The final implementation almost never matches what was described because during the lengthy implementation and stabilization process we encounter multitude of unknown unknowns. The work of the spec writers will be to go back and document the result of that process. For what is worth the seeming dragging of feet on this is because the people that would be qualified and inclined to doing that work were working on other, more pressing matters. If we had had a spec back in, let's say, Rust 1.31, what would have that changed, in practice?
  - gkbrk 3y ago
    > If the compiler you use and the spec of your language disagree, what do you do? If the compiler claims to follow the specified version of the spec, and it doesn't, you file a compiler bug. And then use the subset that it supports, perhaps by using an older spec if it supports that fully. Perhaps looking for alternative compilers that have better/full coverage of a spec. "Supports the spec minus these differences" is still miles better than "any behaviour can change because the Rust 2.1.0 compiler compiles code that the Rust 2.1.0 compiler compiles".
    - estebank 3y ago
      > If the compiler claims to follow the specified version of the spec, and it doesn't, you file a compiler bug. > And then use the subset that it supports, perhaps by using an older spec if it supports that fully. Perhaps looking for alternative compilers that have better/full coverage of a spec. If you encounter rustc behavior that seems unintentional, you can always file a bug in the issue tracker against the compiler or language teams[1]. Humans end up making a determination whether the behavior of the compiler is in line with the RFC that introduced the feature. > "Supports the spec minus these differences" is still miles better than "any behaviour can change because the Rust 2.1.0 compiler compiles code that the Rust 2.1.0 compiler compiles". You can look at the Rust Reference[2] for guidance on what the language is supposed to be. It is explicitly not a spec[3], but the project is working on one[4]. 1: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3At-lang https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... 2: https://doc.rust-lang.org/reference/introduction.html https://doc.rust-lang.org/reference/introduction.html 3: https://doc.rust-lang.org/reference/introduction.html#what-the-reference-is-not https://doc.rust-lang.org/reference/introduction.html#what-t... 4: https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
  - throwaway17_17 3y ago
    Can you articulate what a spec for a programming language entails in your mind. I am sure it is a niche opinion/position, but I base any discussions of formal specification of a language on ‘The Definition of ML’. With that as a starting point I don’t see how the implementation process of a compiler would do anything that could force a change to the spec. Once the formal syntax is defined, the static and dynamic semantics of the language laid out and those semantics proved approximately consistent and possessing ‘type safety’ (for some established meaning of the words). Any divergence or disagreement is a failing of the implementation. I’m genuinely interested in what you expect a specification of Rust to be if, as your comment suggests, you have a different point of view?

_gabe_ 3y ago

This is definitely not true. Whenever I have a question about a C++ language feature I typically go here first[0], and then if I’m looking for compiler specific info I go to the applicable compiler docs second. Likewise, for Java I go here[1]. For JavaScript I typically reference Mozilla since those docs are usually well written, but they reference the spec where applicable and I dig deeper if needed[2]. Now, none of these links are the specifications for the languages listed, but they all copiously link to the specification where applicable. In rare situations, I have gone directly to the specification. That’s usually if I’m trying to parse a subset of the language or understand an obscure language feature. I would argue no one writes code against a compiler. Sure we all validate our code with a compiler, but a compiler does not tell you how the language works or interacts with itself. I write my code and look for answers to my questions in the specification for my respective languages, and I suspect most programmers do as well. [0]: https://en.cppreference.com/w/ https://en.cppreference.com/w/ [1]: https://docs.oracle.com/javase/specs/index.html https://docs.oracle.com/javase/specs/index.html [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript

estebank 3y ago
If the compiler you use and the spec of your language disagree, what do you do? The Project is working on a specification. The Foundation hired someone for it. A Rust spec done purely on paper ahead of time would be the contents of the accepted RFCs. The final implementation almost never matches what was described because during the lengthy implementation and stabilization process we encounter multitude of unknown unknowns. The work of the spec writers will be to go back and document the result of that process. For what is worth the seeming dragging of feet on this is because the people that would be qualified and inclined to doing that work were working on other, more pressing matters. If we had had a spec back in, let's say, Rust 1.31, what would have that changed, in practice?
- gkbrk 3y ago
  > If the compiler you use and the spec of your language disagree, what do you do? If the compiler claims to follow the specified version of the spec, and it doesn't, you file a compiler bug. And then use the subset that it supports, perhaps by using an older spec if it supports that fully. Perhaps looking for alternative compilers that have better/full coverage of a spec. "Supports the spec minus these differences" is still miles better than "any behaviour can change because the Rust 2.1.0 compiler compiles code that the Rust 2.1.0 compiler compiles".
  - estebank 3y ago
    > If the compiler claims to follow the specified version of the spec, and it doesn't, you file a compiler bug. > And then use the subset that it supports, perhaps by using an older spec if it supports that fully. Perhaps looking for alternative compilers that have better/full coverage of a spec. If you encounter rustc behavior that seems unintentional, you can always file a bug in the issue tracker against the compiler or language teams[1]. Humans end up making a determination whether the behavior of the compiler is in line with the RFC that introduced the feature. > "Supports the spec minus these differences" is still miles better than "any behaviour can change because the Rust 2.1.0 compiler compiles code that the Rust 2.1.0 compiler compiles". You can look at the Rust Reference[2] for guidance on what the language is supposed to be. It is explicitly not a spec[3], but the project is working on one[4]. 1: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3At-lang https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... 2: https://doc.rust-lang.org/reference/introduction.html https://doc.rust-lang.org/reference/introduction.html 3: https://doc.rust-lang.org/reference/introduction.html#what-the-reference-is-not https://doc.rust-lang.org/reference/introduction.html#what-t... 4: https://blog.rust-lang.org/inside-rust/2023/11/15/spec-vision.html https://blog.rust-lang.org/inside-rust/2023/11/15/spec-visio...
- throwaway17_17 3y ago
  Can you articulate what a spec for a programming language entails in your mind. I am sure it is a niche opinion/position, but I base any discussions of formal specification of a language on ‘The Definition of ML’. With that as a starting point I don’t see how the implementation process of a compiler would do anything that could force a change to the spec. Once the formal syntax is defined, the static and dynamic semantics of the language laid out and those semantics proved approximately consistent and possessing ‘type safety’ (for some established meaning of the words). Any divergence or disagreement is a failing of the implementation. I’m genuinely interested in what you expect a specification of Rust to be if, as your comment suggests, you have a different point of view?