-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stabilizable subset of const generics #332
Comments
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. |
Kicking off the FCP. I personally see no difficulties here @rfcbot fcp merge |
Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
We're not doing seconding for this? |
For public facing changes, FCP is required, but for stabilizations it's usually attached to the PR. It seems like the first step here is going to be carving out a distinct feature gate for this subset and then stabilizing that, and I don't think that necessarily requires FCP. Nonetheless, I approve of the idea. |
Prioritization automation failed because the bot didn't add the |
Added rfcbot with write permissions to this repo. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
I'm ok with this if wg-const-eval and eddyb are sure that the implementation is no longer at prototype stage, and the stabilized subset won't have issues that can't be fixed backward compatibly (due to lazy normalization, scoping of generic parameter environment, or what other problems we had). |
We recently had a lang-team meeting on this with those folks present. We'll definitely be digging into that before we fully stabilize things. |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Implement the `min_const_generics` feature gate Implements both rust-lang/lang-team#37 and rust-lang/compiler-team#332. Adds the new feature gate `#![feature(min_const_generics)]`. This feature gate adds the following limitations to using const generics: - generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`) - generic parameters must be either integers, `bool` or `char`. We do allow arbitrary expressions in associated consts though, meaning that the following is allowed, even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable. ```rust trait Foo { const ASSOC: usize; } impl<const N: usize> Foo for [u8; N] { const ASSOC: usize = 64 / N; } ``` r? @varkor cc @eddyb @withoutboats
(For those who come across this issue, rust-lang/rust#74878 is the right place to track this now) |
Proposal
We should create a new feature
min_const_generics
, which contains a subset of the const generics feature suitable for stabilization.This will impose two restrictions on const generics:
N
)The latter will be implemented simply syntactically: if an expression contains a type or const parameter in its macro-expanded AST, it will error, unless it is just the name of a const generic.
This feature will not depend on lazy normalization of consts.
Mentors or Reviewers
@eddyb @varkor @oli-obk
Process
The main points of the Major Change Process is as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
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.
The text was updated successfully, but these errors were encountered: