Stabilise feature(const_generics_defaults)

[BoxyUwU]

feature(const_generics_defaults) is complete implementation wise and has a pretty extensive test suite so I think is ready for stabilisation.

needs stabilisation report and maybe an RFC 😅

r? @lcnr
cc @rust-lang/project-const-generics

[bors]

☔ The latest upstream changes (presumably #90516) made this pull request unmergeable. Please resolve the merge conflicts.

[BoxyUwU]

Stabilization report

This is the stabilization report for const parameter defaults and the removal of the type and const parameter ordering restriction. Its feature is #![feature(const_generics_defaults)].

This report is a collaborative effort of @BoxyUwU and @lcnr.

Summary

While supplying default arguments for type parameters is already possible on stable, this is not allowed for const parameters. Due to the restriction that type parameters must be in front of all const parameters, type parameter defaults cannot be used on stable if a const parameter exists.

This stabilization allows type and const parameters to be in an arbitrary order and adds the ability to specify default values for const parameters in all places where this is already allowed for type parameters. These defaults have the same restriction as other const arguments, so they must either be a fully concrete expression or another const parameter.

Motivation

Const parameter defaults

• Reduces the difference between const generics and type generics by allowing both to have defaults
• Allows libraries to backwards compatibly add const generics to traits and types
• Makes working with const generics more ergonomic when there is a reasonable default for the generic parameter

Removal of the ordering restriction

• Type and const parameters are similar enough and there are cases where a specific order of generic parameters is prefered for clarity.
• It is not possible to have generics with both a type default (T = 32) and a const generic (const N: u8) without removing the ordering restriction

Examples

struct ArrayStorage<T, const N: usize = 2> {
    arr: [T; N],
}

impl<T> ArrayStorage<T> {
    fn new(a: T, b: T) -> ArrayStorage<T> {
        ArrayStorage {
            arr: [a, b],
        }
    }
}


struct Image<
    const WIDTH: usize,
    const HEIGHT: usize,
    // Without loosening the ordering restriction,
    // we could not add a default for this type parameter.
    FORMAT: ImageFormat = PngFormat, 
> {
    // ...
}

// This order is a lot clearer than
//
//    T, U, V, F, const N: usize, const M: usize
fn cartesian_product<
    T, const N: usize,
    U, const M: usize,
    V, F
>(a: [T; N], b: [U; M]) -> [[V; N]; M]
where
    F: FnMut(&T, &U) -> V
{
    // ...    
}

Detailed feature description

Ordering

The ordering restriction between types and consts is removed. The ordering of generic params is now: lifetimes, then type and const parameters.

We previously restricted the ordering due to implementation concerns, which have since been fixed.

Example

struct Foo<
    T, 
    const N: usize, 
    U, 
    const M: usize = 3
    V = [i64; M],
>(T, U, V);

fn foo<const N: usize, T, const M: usize>() { }

Default const parameters

It is currently possible to provide a default type to type parameters in type and trait definition. With this stabilization it becomes possible to provide default values for const parameters as well.

The used syntax is const PARAM_NAME: Ty = expr where expr is either a single segment path, a literal, or surrounded by braces, e.g. { foo() }. This restriction is identical to the restriction of const parameters and simplifies parsing.

Const defaults, for now, are not permitted to involve computations depending on generic parameters. This means that defaults may only be:

1. const expressions that do not depend on any generic parameters, e.g. { foo() + 1 }, where foo is a const fn.
2. standalone const parameters, e.g. N. Note that both type and const parameter defaults may only refer to preceeding parameters, meaning that struct Foo<const N: usize = M, const M: usize = 3> causes an error.

When using an expression which does not evaluate successfully, e.g. usize::MAX + 1, as a const parameter default, we eagerly emit an error. This also mirrors the behavior of type parameter defaults.

The decision whether const parameter defaults are used or the parameter has to be inferred is directly taken from the existing behavior of type parameter defaults.

Example

struct Foo<const N: usize = 10>;
struct Bar<const N: usize = { usize::MAX - 1 }, const M: usize = N>;

fn foo() -> (Foo, Bar<10>) {
    (Foo::<10>, Bar)
}

struct Baz<const N: usize, const M: usize = { N + 1 }>;
//^ error: generic parameters may not be used in const operations

trait Trait<const N: usize> { const ASSOC: usize; }
pub struct UwU<const N: usize = { <()>::ASSOC }> where (): Trait<N>;
//^ error: no associated item named `ASSOC` found for unit type `()` in the current scope

Documentation

The Book: Does not contain any documentation about const generics
The Reference: rust-lang/reference#1098

Important Tests

• Trait objects
  • trait_objects.rs
  • trait_objects_fail.rs
• Impl Trait
  • rp_impl_trait.rs
  • rp_impl_trait_fail.rs
• Wfness
  • wfness.rs
  • default-param-wf-concrete.rs
• Inference
  • doesnt_infer.rs (tests that we dont use defaults to aide type inference)
• Ordering
  • forward-declared.rs
  • intermixed-lifetime.rs
  • wrong-order.rs
  • complex-unord-param.rs

Future Incompatibilty concerns

trait Trait<T> {
    const ASSOC: usize;
}

impl Trait<()> for usize {
    const ASSOC: usize = 2;
}

struct Foo<T, U, const N: usize = { usize::ASSOC }>(T, U)
where
    usize: Trait<T> + Trait<U>;

usize::ASSOC is resolved today, but will be ambiguous if we start providing where clauses to type level constants. This is not a new issue however, as the following code has the same issue and currently compiles on stable:

fn foo<T, U>() -> [(); { usize::ASSOC }] 
where
    usize: Trait<T> + Trait<U> {
  ...
}

struct Foo<T, U>(T, U, [(); { usize::ASSOC }])
where
    usize: Trait<T> + Trait<U>;

We therefore believe that this issue should not block the stabilization of const parameter defaults.

[nikomatsakis]

@rfcbot fcp merge

I am kicking off an FCP for stabilization report here

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

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.

[scottmcm]

Thanks for the report!

It looks to me (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=68f0f12f1dde47e0100411fe551c0288) like the inference rules for this match the ones for types, which was my biggest question here.

Const defaults, for now, are not permitted to involve computations depending on generic parameters.

Is there a separate gate for this? Or a test that it's not inadvertently stabilized?

[lcnr]

Is there a separate gate for this? Or a test that it's not inadvertently stabilized?

the gate for this is generic_const_exprs and we do have a test for this:

rust/src/test/ui/const-generics/defaults/complex-generic-default-expr.rs

Lines 1 to 13 in a7836bf

	// revisions: full min
	//[full] check-pass
	#![cfg_attr(full, feature(generic_const_exprs))]
	#![feature(const_generics_defaults)]
	#![allow(incomplete_features)]
	struct Foo<const N: usize, const M: usize = { N + 1 }>;
	//[min]~^ ERROR generic parameters may not be used in const operations
	struct Bar<T, const TYPE_SIZE: usize = { std::mem::size_of::<T>() }>(T);
	//[min]~^ ERROR generic parameters may not be used in const operations
	fn main() {}

the inference rules for this match the ones for types

yes, whether const parameter defaults are used is decided in the same way as for type parameters. Added a sentence to the report itself for this.

[rfcbot]

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

[rfcbot]

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.

This will be merged soon.

[lcnr]

some stuff for future prs.

[lcnr]

we should be able to change this to

pub enum ParamKindOrd {
    Lifetime,
    TypeOrConst,
}

should make stuff a bit cleaner.

[lcnr]

That comment seems outdated and we should enable rustfix for this test

[lcnr]

A huge thanks to @JulianKnodt and @lqd for doing most of the early implementation work of this feature and to @varkor for reviewing their work!

Its kind of funny to me that back when I started to work on const generics, having const params in front of type parameters was breaking the compiler. As I believed that we actually want to keep that strict ordering, I simply sorted the generic params before they caused any problems in #70032. Only a few months later I understood what was going wrong there and was able to fix that in #74676.

---

this change might very slightly improve perf.

@bors r+ rollup=never

[bors]

💔 Test failed - checks-actions

[lcnr]

@bors r+ rollup=never

[bors]

📌 Commit 1e896df has been approved by lcnr

[bors]

⌛ Testing commit 1e896df with merge 753e569...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing 753e569 to master...

[rust-timer]

Finished benchmarking commit (753e569): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression