3 ms·

I think this logic is flawed. If we find a bug in the compiler, is that now a guaranteed behaviour as being the implicit spec? I think a spec is different in a

I think this logic is flawed. If we find a bug in the compiler, is that now a guaranteed behaviour as being the implicit spec? I think a spec is different in a way that allows it to document expected behaviour vs implemented behaviour

rowanG077 4y ago
A traditional spec doesn't fix that issue it has "bugs" too. I'd wager even more so since it isn't runnable and has much less eyeballs. But you have a point that a traditional spec can underspecify behaviour in a way that is not possible in Rust itself. But I content that underspecified behavior in a programming language should be avoided.
- im3w1l 4y ago
  At least if you have a spec and an implementation, you have two descriptions. We can then have some hope that any bug isn't present in both of them, and we can decide which of the two was more reasonable.
  - rowanG077 4y ago
    We do (or very soon will) have that for Rust as well with the gcc front end.
tialaramex 4y ago
Because of the Crater runs which Mara mentions, the Rust teams are actually in a good place to judge what the right call here is. In practice, for a programming language, even something relatively simple like C, the specification is too woolly to be enough, and so the fact of what compilers actually do matters. So Rust having a specification would not magically prevent this problem. Rust's Crater runs allow sunlight from the real world to intrude into decision making. Suppose it is discovered that although the docs say X doesn't happen, actually the compiler does X. Instead of "I bet lots of people rely on X, we must change the specs to match" versus "I bet everybody trusted our spec, which says X doesn't happen, fix the compiler" we have real facts. "Popular crates cool_stuff and jims_other_stuff both rely on X in versions from the last 18 months. Their authors both said they tried this and assumed the documentation was wrong. We should update the documentation to match reality" vs "There's only one crate which uses X, it's a test case in a sub-component of obscure_doodad 0.0.1 from 2017, it appears to receive no usage, and two of the other test cases in obscure_doodad fail on current Rust, so perhaps it is just broken anyway? We should just fix the compiler" The C++ people couldn't have done this twenty years ago. Today they probably could attempt this with various Free Software C++ codebases out there (e.g. GitHub's C++ projects), but as well as considerable technical effort to attempt this, it would be a political burden because lots of non-Free stuff believes it has secret sauce and so vague and unsourced claims about what does or doesn't exist in proprietary C++ are a big problem for compatibility. If you're on team "Don't change X" of course you'll claim huge industrial partners you've seen rely on X in code you can't show anybody. If you're on team "X is obsolete garbage no-uses" you'll claim it's apparent nobody relies on X. This is much less true for Rust. There obviously is proprietary Rust, including in-house projects and stuff that's deliberately proprietary rather than just nobody cared, but Crate covers a lot of what's out there.
- mjw1007 4y ago
  Right: "the testsuites visible to Crater are the de-facto spec" is much closer to the truth than "what rustc currently does is the de-facto spec".

rowanG077 4y ago

A traditional spec doesn't fix that issue it has "bugs" too. I'd wager even more so since it isn't runnable and has much less eyeballs. But you have a point that a traditional spec can underspecify behaviour in a way that is not possible in Rust itself. But I content that underspecified behavior in a programming language should be avoided.

im3w1l 4y ago
At least if you have a spec and an implementation, you have two descriptions. We can then have some hope that any bug isn't present in both of them, and we can decide which of the two was more reasonable.
- rowanG077 4y ago
  We do (or very soon will) have that for Rust as well with the gcc front end.

tialaramex 4y ago

Because of the Crater runs which Mara mentions, the Rust teams are actually in a good place to judge what the right call here is. In practice, for a programming language, even something relatively simple like C, the specification is too woolly to be enough, and so the fact of what compilers actually do matters. So Rust having a specification would not magically prevent this problem. Rust's Crater runs allow sunlight from the real world to intrude into decision making. Suppose it is discovered that although the docs say X doesn't happen, actually the compiler does X. Instead of "I bet lots of people rely on X, we must change the specs to match" versus "I bet everybody trusted our spec, which says X doesn't happen, fix the compiler" we have real facts. "Popular crates cool_stuff and jims_other_stuff both rely on X in versions from the last 18 months. Their authors both said they tried this and assumed the documentation was wrong. We should update the documentation to match reality" vs "There's only one crate which uses X, it's a test case in a sub-component of obscure_doodad 0.0.1 from 2017, it appears to receive no usage, and two of the other test cases in obscure_doodad fail on current Rust, so perhaps it is just broken anyway? We should just fix the compiler" The C++ people couldn't have done this twenty years ago. Today they probably could attempt this with various Free Software C++ codebases out there (e.g. GitHub's C++ projects), but as well as considerable technical effort to attempt this, it would be a political burden because lots of non-Free stuff believes it has secret sauce and so vague and unsourced claims about what does or doesn't exist in proprietary C++ are a big problem for compatibility. If you're on team "Don't change X" of course you'll claim huge industrial partners you've seen rely on X in code you can't show anybody. If you're on team "X is obsolete garbage no-uses" you'll claim it's apparent nobody relies on X. This is much less true for Rust. There obviously is proprietary Rust, including in-house projects and stuff that's deliberately proprietary rather than just nobody cared, but Crate covers a lot of what's out there.

mjw1007 4y ago
Right: "the testsuites visible to Crater are the de-facto spec" is much closer to the truth than "what rustc currently does is the de-facto spec".