Skip to content

Add const generics 2025h2 goal #313

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add const generics 2025h2 goal #313

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
abb73de
Add const generics 2025h2 goal
BoxyUwU Jun 16, 2025
fdf496b
gai is done actually
BoxyUwU Jun 20, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions src/2025h2/const-generics.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Const Generics

| Metadata | |
|:-----------------|-------------|
| Point of contact | @BoxyUwU |
| Teams | lang |
| Task owners | @BoxyUwU |
| Status | Proposed |
| Tracking issue | |
| Zulip channel | N/A |

## Summary

Work towards stabilizing the remaining const generics functionality that was left out of the original `min_const_generics` feature.

## Motivation & Status Quo

The `min_const_generics` feature was stabilized with a number of limitations, while some have since been lifted there are still some things we do not support:
- Inferred arguments to const parameters (`feature(generic_arg_infer)`)
- Const parameters with arbitrary user-defined types (`feature(adt_const_params)`)
- Non-concrete uses of associated constants in the type system (`feature(min_generic_const_args)`/`feature(associated_const_equality)`)

When using const generics it is common to run into these limitations and be unable to move forwards, having to rewrite your code to use workarounds or not use const generics at all. This is a poor user experience and makes the language feel incomplete.

### The next 6 months

- Write a document outlining the main design decisions of `adt_const_params` and discuss it with the lang team, follow up with an RFC
- Finish implementing the `min_generic_const_args` (mgca) feature prototype

### The "shiny future" we are working towards

All parts of the const generics feature that were left out of the minimum stabilization have now been stabilized. Users do not encounter "functionality cliffs" where const generics
suddenly stops working as well as type generics, forcing code to be rewritten to work around language limitations.

## Ownership and team asks

| Task | Owner(s) or team(s) | Notes |
|-----------------------------------|---------------------|-------|
| `adt_const_params` design meeting | [lang] | |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, wearing my @rust-lang/lang hat for a moment, I'm keen to see this work go foward, but I also am aware we've had some miscommunication in this area for a while now. Maybe it'd be good to start with a more general design meeting, basiically starting out with a doc that tries to give everybody a general grounding in how const generics works, how it interacts with const eval, what some of the challenges are? There wouldn't be any decisions to make, it'd just be a knowledge sharing (and documenting) session.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Knowing what I know about adt_const_params, a there-focused meeting could still be a good general meeting because discussing adt_const_params re: getting it ready towards landing does imply summarizing the state of "what we can do in const generics without question, and what will require design decisions to advance". Does that still rhyme with what you have in mind?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be, yes. Put another way, I just don't see us getting through everything in 1 meeting, not really.

Copy link
Member

@workingjubilee workingjubilee Jun 19, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. Notably, this proposal kinda elides, by focusing on the next 6 months, that already some things were cut out from adt_const_params as a feature to get it down towards things that we could ship sooner. So maybe the meeting would also (briefly) discuss the longer trajectory and why those things are blocked and not shipping with other things.

Copy link
Member Author

@BoxyUwU BoxyUwU Jun 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can put another meeting on here that seems reasonable 🤔

Copy link
Member Author

@BoxyUwU BoxyUwU Jun 20, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "talk about the challenges" doesn't really work if we were to go into much depth though. the main thing i would expect an adt_const_params design meeting to involve would be covering all of the challenges involved. and I expect that to take up an entire meeting. talking about the challenges of all const generics features in anything other than a very shallow way is likely not possible 🤔

| `adt_const_params` RFC draft | @BoxyUwU | |
| Finish `mgca` prototype | @BoxyUwU @camelid | |
Loading