Skip to content
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

Closed
1 of 3 tasks
withoutboats opened this issue Jul 16, 2020 · 12 comments
Closed
1 of 3 tasks

Stabilizable subset of const generics #332

withoutboats opened this issue Jul 16, 2020 · 12 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@withoutboats
Copy link

withoutboats commented Jul 16, 2020

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:

  1. They can only have the type of an integral primitive type (integers, bool, and char).
  2. Expressions used in const generic position must be either:
    • Just a const generic name in scope (e.g. N)
    • A const expression which contains on no free type or const parameters.

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:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

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.

@withoutboats withoutboats added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels Jul 16, 2020
@rustbot
Copy link
Collaborator

rustbot commented Jul 16, 2020

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.

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Jul 16, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Jul 16, 2020

Kicking off the FCP. I personally see no difficulties here

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 16, 2020

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.

@eddyb
Copy link
Member

eddyb commented Jul 16, 2020

We're not doing seconding for this?

@nikomatsakis
Copy link
Contributor

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.

@spastorino spastorino removed the to-announce Announce this issue on triage meeting label Jul 22, 2020
@spastorino
Copy link
Member

spastorino commented Jul 23, 2020

Prioritization automation failed because the bot didn't add the proposed-final-comment-period label. I've fixed T-compiler agenda manually. Maybe @rfcbot doesn't have permission to add labels to issues in this repo?.

cc @Mark-Simulacrum

@Mark-Simulacrum
Copy link
Member

Added rfcbot with write permissions to this repo.

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 28, 2020

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Jul 28, 2020
@petrochenkov
Copy link

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).

@nikomatsakis
Copy link
Contributor

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.

@rfcbot rfcbot added finished-final-comment-period The FCP has finished, action upon the disposition label needs to be taken and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Aug 7, 2020
@rfcbot
Copy link
Collaborator

rfcbot commented Aug 7, 2020

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.

bors added a commit to rust-lang-ci/rust that referenced this issue Aug 8, 2020
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
@spastorino spastorino added major-change-accepted A major change proposal that was accepted and removed finished-final-comment-period The FCP has finished, action upon the disposition label needs to be taken labels Aug 20, 2020
@rustbot rustbot added the to-announce Announce this issue on triage meeting label Aug 20, 2020
@spastorino spastorino removed the to-announce Announce this issue on triage meeting label Aug 20, 2020
@alex
Copy link
Member

alex commented Aug 20, 2020

(For those who come across this issue, rust-lang/rust#74878 is the right place to track this now)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Development

No branches or pull requests

10 participants