Tracking issue for `associated_consts` feature

[aturon]

The feature is currently quite buggy, but this issue tracks its eventual stabilization.

• Blocked on const_fn.
• Type params in const expressions (associated-constants can not be used in constant expressions #34344 / cannot use an outer type parameter in this context #39211)
• Associated consts and object safety (Associated constants should not be object safe #26847)
• Do not always require T: 'static for T::CONST
• Associated constants not fully checked between trait and impl (rustc_typeck::check::compare_method::compare_const_impl doesn't drain its fullfillment context nor invoke regionck. #41323)
• Docs
  • add associated constants to items reference reference#75

Shortcomings of the current implementation

Associated consts in const expressions must be concrete

Associated consts can only be used in const contexts if their input types are fully concrete. That is, this works:

trait Foo {
     const X: usize;
}

impl Foo for () {
     const X = 0;
}

let y: [i32; <() as Foo>::X];

But this does not work:

fn foo<T: Foo>() {
    let y: [i32; <T as Foo>::X];
}

Associated consts are never object safe

Associated consts make a trait non-object-safe. There is no way to bound the const where Self: Sized, nor to specify the const when creating the object.

trait Foo {
    const FOO: i32;
}

// Not allowed:
Box<Foo<FOO = 0>>

trait Bar {
    // Not allowed
    const BAR: i32 where Self: Sized;
}

Associated consts referencing other associated consts have spurious destructor warnings

This works:

trait Foo {
    const FOO: Option<i32>;
}

trait Bar: Foo + 'static {
    const BAR: Option<i32> = <Self as Foo>::FOO;
}

But this does not, because we (unnecessarily) assume the const could be a variant that runs a destructor:

trait Foo {
    const FOO: Option<String>;
}

trait Bar: Foo + 'static {
    const BAR: Option<String> = <Self as Foo>::FOO;
}

[raindev]

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose? Given that Rust have default methods it shouldn't be much less ergonomic. And combination of monomorphisation and static lifetimes should converge any difference in terms of performance.

[ketsuban]

One notable case is that of the Zero and One traits, which exist solely to confer their constant value to the types which implement them. With associated constants they would be redundant, as Sum and Mul would include the additive and multiplicative identities.

[raindev]

@ketsuban how would it be different than including zero and one as functions into Sum and Mul traits?

[raindev]

Having skimmed through #27739 it looks like there're opinions about the concepts of "zero" and "one" as functions as it may give additional flexibility.

[mitaa]

@raindev

Why aren't ordinary functions good enough for the same purpose?

https://github.com/rust-lang/rfcs/blob/master/text/0195-associated-items.md#user-content-expressiveness

[elinorbgr]

The use of associated consts could make things like bitflags! more pretty in my opinion, by scoping the consts in the name of the bitflags struct, much like enum variants are scoped in the name of the enum.

[Roxxik]

would love to use associated consts for array sizes for example: http://is.gd/VSee6B

struct Something {
    inner: [u8; Something::LENGTH]
}

but this will leave me at E0250

[Robbepop]

I'm curious about the reasons behind this feature. Why aren't ordinary functions good enough for the same purpose?

I am not sure about this but I think that associated constants could allow us compile time execution for things similar to non-type template parameters as in C++ which are quite useful. Using functions wouldn't work in the example below since Rust currently has no mechanism to detect if a function can be evaluated at compile-time (constexpr as in C++ or even templates).

Example:
https://gist.github.com/Robbepop/da73db721c22492616f6

If the example above really works (haven't tested it, yet) things like BitFlag or the shown BigInt could be implemented very efficiently - not using the heap at all!

[Boddlnagg]

Is there any ETA on the stabilization of this feature? It would be really useful for something which I'm currently experimenting with, namely the implementation of Windows COM interop: One could add a trait that exposes each interface's GUID and/or class ID as constants, then e.g. this API could be mapped to Rust in a way that takes the to-be-activated class as a type parameter that implements said trait.

Of course I can work on this using nightly, but it would be nice to have some information whether the feature is going to be stabilized in the near future!