Skip to content

Experimental language specification #627

Description

@tomassedovic
Metadata
Point of contact @jackh726
Team(s) lang, spec, types
Goal document 2026/experimental-language-specification

Summary

Create an experimental/nightly version of a language specification, based on a branch of the Rust Reference with the addition of stability markers and corresponding tooling. Develop and refine processes around it. (This could theoretically use the Reference directly, but for experimentation purposes it likely makes sense to make it a separate repository, depending on how we can best implement and experiment with this new process without gating on its adoption.)

Do an N=1 case study using the types team as the exemplar, on what it would look like to integrate this with the processes of various teams, with extensive documentation to facilitate scaling this to other teams of domain experts within the project. This case study would include:

  • The handling of proposed changes that fall within the purview of that team, where the types team would review the proposed content.
  • The handling of changes from that team, which would be reviewed by other members of the team. This includes ensuring that prospective language changes arising from the work of the team get flagged as needing documentation changes, and the documentation occurs contemporaneously with the language changes.
  • How and when to merge text with unstability markers (whether "unstable text" or "unstable Rust feature"), and what process to follow to review and remove the markers so that text is considered stable.

As a case study, we can use current work on const generics, RTN, or const traits. All of those would heavily overlap with the purview of the types team. (Lang would make design calls on the feel of the language, but the detailed semantics and recommendations typically fall under the types team.)

This goal may potentially align with separate work to improve lang processes, but that work would not be part of this project goal.

This goal will collaborate with the goal to integrate a-mir-formality into language specifications, though neither goal will block on the other.

Tasks and status


Note: we have updated the body to match the 2026 goal. Your original text is preserved below.

Details

Metadata
Point of contact @jackh726
Team(s) lang, spec, types
Goal document 2026/experimental-language-specification

Summary

Create an experimental/nightly version of a language specification, based on a branch of the Rust Reference with the addition of stability markers and corresponding tooling. Develop and refine processes around it. (This could theoretically use the Reference directly, but for experimentation purposes it likely makes sense to make it a separate repository, depending on how we can best implement and experiment with this new process without gating on its adoption.)

Do an N=1 case study using the types team as the exemplar, on what it would look like to integrate this with the processes of various teams, with extensive documentation to facilitate scaling this to other teams of domain experts within the project. This case study would include:

  • The handling of proposed changes that fall within the purview of that team, where the types team would review the proposed content.
  • The handling of changes from that team, which would be reviewed by other members of the team. This includes ensuring that prospective language changes arising from the work of the team get flagged as needing documentation changes, and the documentation occurs contemporaneously with the language changes.
  • How and when to merge text with unstability markers (whether "unstable text" or "unstable Rust feature"), and what process to follow to review and remove the markers so that text is considered stable.

As a case study, we can use current work on const generics, RTN, or const traits. All of those would heavily overlap with the purview of the types team. (Lang would make design calls on the feel of the language, but the detailed semantics and recommendations typically fall under the types team.)

This goal may potentially align with separate work to improve lang processes, but that work would not be part of this project goal.

This goal will collaborate with the goal to integrate a-mir-formality into language specifications, though neither goal will block on the other.

Tasks and status

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions