You're part of the way there. Think less feature development, more architecture & governance.
A language reference is like documentation and a language specification is like a contract. If I uncover behavior in a system that isn’t documented, then I will update the documentation. But if the behavior fails to match the (formal) spec, then the system is at fault for not meeting the expectations of the contract, and the system needs to be corrected. As https://github.com/rust-lang/rfcs/pull/3355#issuecomment-134... states:
> If you built a rocket and that rocket crashes, you wouldn't update the spec of the rocket to say "it is expected to crash after reaching 3000m altitude". But if you made a typo that says the rocket should crash after reaching 3000m altitude and somehow passed review, you wouldn't add a self detonation device into the rocket just because of this either.
In contexts like safety critical/offline environments, the consequences of unexpected behavior can be dire and hard to fix in the moment (e.g. airplanes in flight). Liability becomes a real concern, and outside parties need a "contract" to be confident certain expectations or behaviors will be met in perpetuity. The reference doesn't offer that guarantee, and has understood itself to be a best-effort technical reference, despite attempts to increase its authoritativeness into a spec https://github.com/rust-lang/reference/issues/629
My opinion is that the spec is actually more needed for people inside the language than for people outside. Like the contractual element of a language spec fulfills a constitutional, if not judicial role, in the development process. However, I've learned requires a level of integrity that Rust can no longer hope to achieve.
My perspective of following the compiler development is that very often much needed features aren’t developed because of outside constraints - lack of a person to push it through, lack of consensus on how to implement it and the codebase not being built in a way that supports the feature at all.
A couple of features spring to mind - partial borrows of strict fields by methods and several “obvious” improvements to the type system. I think everyone wants the first feature but it’s hard to implement in the current borrowchecker codebase. Similarly, many features are blocked on the next gen trait solver because the current one is crusty and difficult to work with. Fortunately, I think they’re relatively close with the latter. I believe rust-analyzer is moving to the new trait solver and perhaps rustc will in the future as well. That will unlock a lot of improvements and importantly, fix many soundness issues in the compiler as well.
I can see where you’re coming from. A spec that you can point to allows a user to report a bug with some authority - your implementation is failing to adhere to the spec you wrote. Therefore this bug should be prioritised. And maybe this will lead to higher quality software.
The other perspective is that I’ve seen a lot of good developers, who have a lot of context on the project, leave the project. The reasons vary, but I gather burn out is a common one. They like their coworkers, they like the impact they’re having, but they don’t like a lot of the problems that come with maintaining a large open source project. Entitled people, drive by commenters, a codebase that has developed in layers over 15 years, slow feedback loops on RFCs. I fear that if we added people demanding fixes because of spec adherence, it would be one more source of burnout. This could slow down development as more people leave.
The folks working on the new trait solver are aware of the issues in the existing trait system. You can see all the soundness issues, many of which are tagged T-types here (https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...). They really want to fix these, and they hope the new trait solver makes it easier to get there. The constraints of the implementation appear to be driving which soundness issues get worked on. Issues have been paused with the hope that they will go away or be easy to fix with the new system. All energy goes instead to migrating to the new system.
Would it really help if someone said that hey, according to the project constitution, you’ve committed to fixing spec violations before you do feature work like new trait solver. Maybe, I don’t know. My experience with spec driven development is limited.
But my intuition would be to trust the people who’ve done the development so far. They’ve done a pretty good job of producing a successful, performant language. They’re able to add features much more quickly than most other comparable languages while maintaining a high degree of stability. They’ve supported an ecosystem that has roughly doubled in size every year for 10 years. If they want to do spec driven development, sure. If they don’t, that’s fine with me too.
I want them to choose a development system and a quality bar that they’re happy with. Today it’s RFCs and crater runs. Tomorrow it could be spec and spec. If they’re happy, I’m happy.
A language reference is like documentation and a language specification is like a contract. If I uncover behavior in a system that isn’t documented, then I will update the documentation. But if the behavior fails to match the (formal) spec, then the system is at fault for not meeting the expectations of the contract, and the system needs to be corrected. As https://github.com/rust-lang/rfcs/pull/3355#issuecomment-134... states:
> If you built a rocket and that rocket crashes, you wouldn't update the spec of the rocket to say "it is expected to crash after reaching 3000m altitude". But if you made a typo that says the rocket should crash after reaching 3000m altitude and somehow passed review, you wouldn't add a self detonation device into the rocket just because of this either.
In contexts like safety critical/offline environments, the consequences of unexpected behavior can be dire and hard to fix in the moment (e.g. airplanes in flight). Liability becomes a real concern, and outside parties need a "contract" to be confident certain expectations or behaviors will be met in perpetuity. The reference doesn't offer that guarantee, and has understood itself to be a best-effort technical reference, despite attempts to increase its authoritativeness into a spec https://github.com/rust-lang/reference/issues/629
My opinion is that the spec is actually more needed for people inside the language than for people outside. Like the contractual element of a language spec fulfills a constitutional, if not judicial role, in the development process. However, I've learned requires a level of integrity that Rust can no longer hope to achieve.