Description
This is a tracking issue for the experimental feature associated const equality brought up in #702561 (RFC pending).
The feature gate for the issue is #![feature(associated_const_equality)]
.
About experimental features
An experimental feature is one that has not yet had an RFC. The idea is to allow implementation work to proceed to better inform an upcoming RFC. Experimental features cannot be stabilized without first having an RFC. The existence of an experimental feature does not indicate lang team consensus that the feature is desirable, only that there is a problem that is worthy of being solved and that the idea has enough merit to consider exploring. See the lang team process page for more details.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Fully implement the feature
- Address important open F-associated_const_equality `#![feature(associated_const_equality)]` issues
- Support const projections in the next trait solver
- Address all blocking
FIXME(associated_const_equality)
Write an RFCAdjust documentation (see instructions on rustc-dev-guide)Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
None so far.
Implementation history
- allow eq constraints on associated constants #876482
- Continue work on associated const equality #932853
- Resolve associated item bindings by namespace #118668
- Fix type resolution of associated const equality bounds (take 2) #119385
- Reject overly generic assoc const binding types #121258
Footnotes
-
Original proposal with support but no official RFC, but implementation delayed. ↩
-
Initial effort to implement which includes parsing and use of
term
throughout the codebase, but still lacking a complete implementation. ↩ -
More thorough implementation which works for basic cases. This allowed for consts to actually be bound, more than just parsing them. ↩
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Status
Activity
pushkine commentedon Feb 8, 2022
Hello!
Is there a corresponding RFC, or any context whatsoever concerning those changes ?
This is the first occurrence of language syntax change that is not backed by RFC and community feedback
@Centril @oli-obk
oli-obk commentedon Feb 8, 2022
Well, we have #70256 which indeed has basically no discussion of the feature. It just seemed like an oversight to have associated types + associated type bounds, but only associated consts without any bounds for them.
JulianKnodt commentedon Feb 8, 2022
I probably should've tagged the original issue in this at the start (it was in the original PR if I remember correctly) but I'm bad at leaving a thorough paper trail. I'll add a reference to the original issue in the issue itself, and if there's more work that needs to be done please let know
oli-obk commentedon Feb 8, 2022
You did everything correctly. I found the issue because you did link it in the first sentence in this issue 😄
We should probably do a lang team MCP for it along with some medium sized doc explaining what is going on and why. I'll open a hackmd and then we can collab on it
ices/93835.rs: fixed with errors
associated_const_equality
rust-lang/rust-analyzer#1196534 remaining items
[-]Tracking Issue for Associated Const Equality[/-][+]Tracking Issue for associated const equality[/+]decode: guard against panics when alloc is disabled
.eq_any([["foo"]])
onSqlType = Array<Text>
causes runtime error on Postgres diesel-rs/diesel#4349[-]Tracking Issue for associated const equality[/-][+]Tracking issue for associated const equality[/+]#[godot_dyn]
godot-rust/gdext#1022