Language Design: Fixing Rust’s mistakes

Semantics

Published on 2017-07-20. Last updated on 2025-10-14

As Rust 2.0 is not going to happen, Rust users will never get these language design fixes:123

A note on the lower bar of a hypothetical Rust 2.0

An article touching on "Rust 2.0" and its reactionary reception made it apparent that language evolution has two boundaries, not one:

  • Boundary 1 (upper bar of change): Things a hypothetical language "v2.0" is not allowed to improve for compatibility reasons.
  • Boundary 2 (lower bar of change): Things that a hypothetical language "v2.0" needs to improve for such an effort to be worthwhile to contributors and users.

For Rust, we know the exact coordinates of the first boundary, but very little about the second boundary, as such "critical" engagement is poorly received by the community.

Nevertheless, only a cursory look is needed to conclude that "Rust 2.0" is very unlikely:
The lower bar is above the upper one, i. e. the required changes to make it worthwhile are larger than Rust leadership's acceptance for change.

This doesn't mean that we can't explore the second boundary, and collect these "unacceptable fixes" as a learning opportunity for future language designers!

Remove the hierarchy between Eq/Ord and PartialEq/PartialOrd traits

This allows floating point values to implement a total order based on §5.10 of the IEEE754 spec.4

Rectify “almost rules” into “always rules”

See this article for details.

  1. “Does Rust have any design mistakes?” 

  2. label:rust-2-breakage-wishlist 

  3. Broken and un-fixable parts of Rust 

  4. “Ackchually, float do not have a total order though!?” – Please read the IEEE754 spec.