Description
Proposal
Summary and problem statement
When writing a function taking a &mut argument, it frequently (see *_mut functions in libstd) happens that one also creates a (near-)duplicate function just with an immutable reference. The same is true for async functions, const functions and various other keywords. If one were to combine these keywords, it is not too far fetched that one has an async fn async_get_mut(&mut self), an async fn async_get(&self), a fn get_mut(&mut self) and a fn get(&self) function. Adding more variants of the same function for other keywords duplicates the number of functions for each keyword.
Motivation, use-cases, and solution sketches
For const, the rust-lang/rfcs#2632 was accepted for experimentation to figure out this problem. That RFC even added explanatory (never to be stabilized) syntax to explain the feature in a "constness generic" way. Basically we would like to make functions like Option::unwrap_or_default a const fn. In order to do this, we need to make sure that the generic parameter T has a Default impl that can be evaluated at compile time. But at the same time, we want the function to be usable with types that have Default impl that is not evaluable at compile time, as long as the function is not called from a const context (This is what is allowed on stable today, as there are no const fn with generic parameters that can be invoked). The RFC spelled this out as "const if const" trait bounds, so at present (unstably), we could write
const fn unwrap_or_default<T: ~const Default>(this: Option<T>)-> T {
match this {
Some(val) => val,
None => T::default(),
}
}where ~const is a placeholder syntax meaning "const if const" (If you have seen the RFC, this used to be the opposite, where ?const meant "unknown if const, treated as not const" and the "const if const" part was implied everywhere else).
In the explainer syntax from the RFC this was written as
for<constness C> const<C> fn unwrap_or_default<T: const<C> Default>(this: Option<T>)-> T {
match this {
Some(val) => val,
None => T::default(),
}
}Where you can select at the call site whether you get a const fn or a plain fn by changing the C parameter (or with some sugar it is chosen automatically for you).
We would like to explore these keyword generics in a shared way, instead of just experimenting more with const fn. We don't know the syntax yet and the full scope, but in https://github.com/yoshuawuyts/keyword-generics-initiative we're starting to track the ideas for this feature.
Links and related work
- preliminary implementation (without syntax) for
const: [WIP] Rework the entire const trait system rust#96077 - initiative repo: https://github.com/yoshuawuyts/keyword-generics-initiative
Initial people involved
- Owner, if known: @oli-obk @yoshuawuyts
- Liaison: @nikomatsakis
What happens now?
This issue is part of the lang-team initiative process. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open proposals in its weekly triage meetings. You should receive feedback within a week or two.
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.