Parse unstable keywords for experimental syntax

[dianne]

Proposal

I'm proposing to use k#-prefixed identifiers (such as k#keyword) as keywords in language experiments in a permanently-unstable-until-otherwise-decided fashion. Prefixed identifiers have already been reserved in editions 2021+ by rust-lang/rfcs#3101 but to my knowledge there's no accepted precedent yet for using them in experimental syntax. rust-lang/rfcs#3098 proposes to stabilize the k# prefix as a way to write edition-gated keywords in older editions, but discussion on the RFC has stalled out. I believe having an easy way to introduce experimental keywords for unstable features is useful enough to stand on its own, but this proposal is meant to be future-compatible with the RFC: if it's is later accepted, that opens up stabilization for k# keywords; otherwise, they remain a tool for experimenting with unstable features.

Currently, the alternative options for experimenting with keyword syntax are fairly limited. To my understanding, they're roughly:

• Reserve a keyword for use in future editions. Having a future edition (add a "future" edition rust#137606) helps in that it means we technically wouldn't have to commit to stabilizing reservations, but from what I can tell at least, the future edition is meant as a staging ground for edition migrations rather than as a sandbox for lang experiments.
• Combine a new unreserved keyword with an existing reserved keyword, e.g. as is done by do yeet. This isn't ideal when none of the existing reserved keywords fit the spirit of the experiment.
• Define a built-in macro or a macro wrapper around builtin# syntax (Add builtin# for compiler-intrinsic syntax #580), e.g. as is done by deref!. This is great for prototyping, but not for testing how a feature feels to use.

For experiments where we want to determine the ergonomics of a potential new feature, it's important to minimize the amount of syntactic baggage. An example of this is the proposed is operator (rust-lang/rfcs#3573): as syntactic sugar, there's a large difference between testing expr k#is pat and the equivalent achievable with a macro, is!(expr is pat).

Mentors or Reviewers

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler