Skip to content

Commit 3df8367

Browse files
nikomatsakisnikomatsakis
authored
Merge pull request #227 from nikomatsakis/const-traits-project-goal
proposed project goal for const traits
2 parents ebf8220 + b85ef70 commit 3df8367

File tree

1 file changed

+101
-0
lines changed

1 file changed

+101
-0
lines changed

‎src/2025h1/const-trait.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# Prepare const traits for stabilization
2+
3+
| Metadata | |
4+
|------------------|--------------------------|
5+
| Point of contact | @oli-obk |
6+
| Teams | <!-- TEAMS WITH ASKS --> |
7+
| Task owners | <!-- TASK OWNERS --> |
8+
| Status | Proposed |
9+
10+
## Summary
11+
12+
Prepare `const Trait` bounds for stabilization.
13+
14+
## Motivation
15+
16+
`const fn` on stable are unable to invoke trait methods, limiting their usefulness. After years of experimentation, the compiler now has a promising implementation of `const traits` and key parts of the stdlib have been updated to use it. However, the feature is still firmly in experimental territory: there has never been an RFC describing its syntax.
17+
18+
The goal for the next 6 months is to author an RFC proposing an end-user syntax for const bounds and a specific semantics. Our believe is that the core implementation work is done and that it should be possible to merge the RFC, implement the syntactic choices, issue a public call for experimentation, and otherwise pave the ground for stabilization (stabilization itself is a stretch goal and seems likely to occur in 2025H2).
19+
20+
### The status quo
21+
22+
People write a lot of code that will be run in compile time. They include procedural macros, build scripts ([42.8k hits][build scripts] on GitHub for `build.rs`), and const functions/consts ([108k hits][const fns] on GitHub for `const fn`). Not being able to write const functions with generic behavior is often cited as a pain point of Rust's compile time capabilities. Because of the limited expressiveness of `const fn`, people may decide to move some compile time logic to a build script, which could increase build times, or simply choose not to do it in compile time (even though it would have helped runtime performance).
23+
24+
There are also language features that require the use of traits, such as iterating with `for` and handling errors with `?`. Because the `Iterator` and `Try` traits currently cannot be used in constant contexts, people are unable to use `?` to handle results, nor use iterators e.g. `for x in 0..5`.
25+
26+
[build scripts]: https://github.com/search?q=path%3A**%2Fbuild.rs+NOT+is%3Afork&type=code
27+
[const fns]: https://github.com/search?q=%22const+fn%22+language%3Arust+NOT+is%3Afork&type=code
28+
29+
### The next 6 months
30+
31+
The primary goal is to do "Everything but" stabilization of this feature over the next 6 months
32+
33+
* Author an RFC for `const traits` and get it accepted by the language design team
34+
* Implement the syntax and user experience described in the RFC
35+
* Issue a call for experimentation and resolve any issues found
36+
* Author a stabilization report
37+
38+
As a secondary goal, we will use this as an experiment to drive forward a-mir-formality, with @nikomatsakis and @oli-obk mentoring @tiif to extend a-mir-formality with support for const traits.
39+
40+
### The "shiny future" we are working towards
41+
42+
We're working towards enabling developers to do more things in general within a `const` context. Const traits is a blocker for many future possibilities (see also the const eval [feature skill tree]) including heap operations in const contexts.
43+
44+
[feature skill tree]: https://rust-lang.github.io/const-eval/skill_tree.html
45+
46+
## Design axioms
47+
48+
None.
49+
50+
## Ownership and team asks
51+
52+
Steps towards the primary goal of doing everything towards stabilization apart from approving stabilization itself:
53+
54+
| Task | Owner(s) or team(s) | Notes |
55+
|------------------------------------|--------------------------------|-----------------------------------------------------------------|
56+
| Lang-team experiment | ![Team][] [lang] | ![Complete][] |
57+
| Experimental implementation | @fee1-dead, @compiler-errors | ![Complete][] |
58+
| Author RFC | @oli-obk | ![Complete][] |
59+
| Adjust implementation to match RFC | rust-lang/project-const-traits | |
60+
| Call for testing | @oli-obk | |
61+
| Standard reviews | ![Team][] [compiler] | |
62+
| Design meeting | ![Team][] [lang] | first meeting scheduled for Jan; second meeting may be required |
63+
| RFC decision | ![Team][] [lang] | |
64+
| Secondary review | ![Team][] [types] | Types team needs to validate the approach |
65+
| Author stabilization report | @oli-obk | stretch goal |
66+
67+
### Formalize const-traits in a-mir-formality
68+
69+
Steps towards formalization of the approach in a-mir-formality:
70+
71+
| Task | Owner(s) or team(s) | Notes |
72+
|------------------------------|-------------------------|-----------------------------------------------------------------------------|
73+
| Discussion and moral support | ![Team][] [types] | During types team office hours, we'll share information about our progress. |
74+
| Implementation | @tiif | |
75+
| Mentoring and kibbitzing | @nikomatsakis, @oli-obk | |
76+
77+
### Definitions
78+
79+
Definitions for terms used above:
80+
81+
* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor.
82+
* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
83+
* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
84+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
85+
* *Org decisions* means reaching a decision on an organizational or policy matter.
86+
* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
87+
* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
88+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
89+
* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting.
90+
* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context.
91+
* Other kinds of decisions:
92+
* [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
93+
* Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
94+
* Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.
95+
96+
## Frequently asked questions
97+
98+
### Will we be stabilizing the syntax found on libstd today?
99+
100+
Most likely not. The current syntax includes some controversial notation, such as `T: ~Trait`. The point of the RFC is to determine what syntax will be used. What we hope will not change is the *semantics*.
101+

0 commit comments

Comments
 (0)