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 (#34344 / #39211)
• Associated consts and object safety (#26847)
• Do not always require T: 'static for T::CONST
• Associated constants not fully checked between trait and impl (#41323)
• Docs
  • rust-lang-nursery/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

[vberger]

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!

[nrc]

Should we block on #34344? Are there other known bugs? Are there design questions to resolve here?

[letheed]

There was a question on the forum here. Looks like a bug to me.

[hauleth]

What is status or what would need to be done to stabilize this feature? It would be really helpful in Octavo as it would allow me to provide HMAC without any heap allocations.

[seanmonstar]

@hauleth take a look at the associated-items issues. That contains many of the bugs that exist with associated constants. I imagine many of them would need to be fixed before anyone could consider this feature "stable".

[brson]

How can we accelerate this? This is a major feature and it doesn't appear to be moving or have a champion.

This is used by Rocket.

[brson]

Just nominating to put it in front of eyeballs again.

[steveklabnik]

My understanding is that this is waiting on a re-do of const evaluation in the compiler, since it's so buggy. @eddyb ?

[eddyb]

"Buggy" is not the best way to put it IMO, "barely does anything at all" is far closer.
@brson You can consider @solson, @oli-obk (both miri) and me (rustc) as unofficial champions (for the past several months) for const-eval-related areas.

[steveklabnik]

Yes, it will be in 1.20.

[nwin]

Maybe I’m not seeing the point but as long as “Associated consts in const expressions must be concrete” is still a restriction I do not see any use of associated constants in traits.

Yet you can add them such that all of the error messaged presented in #32344 are still very there and very misleading.

Shouldn’t one simply forbid associated constants in traits unless that restriction is lifted? I dont’t think that it was a good idea merge #42809 (i.e. remove the feature gate) with a feature in such an incomplete state.

[eddyb]

@nwin It's not "in const expressions" - but rather "in types", i.e. array types.

[frehberg]

Is there any plan to introduce LEN (or similar attribute) as associated const for the built-in rust-primitives 'arrray' or 'slice'? , for example

const N : usize = b"my_byte_string"::LEN;

or

is there any plan to declare std::intrinsics::size_of_val(v) as const-fn(?) enabling somehing like:
#![feature(core_intrinsics)]
const N: usize = unsafe { std::intrinsics::size_of_val(b"my_byte_string") };

[eddyb]

@frehberg When const generics are implemented you will be able to do that yourself, for example with an impl<T, const N: usize> MyLenTrait for [T; N]

[robinst]

Anyone landing here from googling "associated const", this was released in Rust 1.20, see the announcement: https://blog.rust-lang.org/2017/08/31/Rust-1.20.html

[robinst]

Also, if anyone is looking for the documentation of this, it's here: https://doc.rust-lang.org/stable/reference/items.html#associated-constants

(It was surprisingly hard to find.)

[SergioBenitez]

Shouldn't equality bounds be possible with associated consts? The following does not compile today:

trait Foo {
    const BAR: usize;
}

// error: expected type, found `10`
fn f<T: Foo<BAR = 10>>() { }

The original associated items RFC makes it clear that this should be possible. I'm wondering: was this simply forgotten about? Or perhaps there are/were complications with implementing this?

[SergioBenitez]

Furthermore, using an associated const as an array size does not appear to work:

pub trait Can {
    const SIZE: usize;
}

fn f<T: Can>(t: T) {
    // error[E0277]: the trait bound `T: Can` is not satisfied
    let x = [0u8; <T as Can>::SIZE];
}

There error message is clearly wrong, so this is either a bug in rustc or unimplemented functionality resulting in a bogus error message.

[shepmaster]

using an associated const as an array size

Probably related to #42863, #44168, #44774 ?

[gnzlbg]

Furthermore, using an associated const as an array size does not appear to work:

This usage of associated const was not stabilized, as documented in this issue (it doesn't work on nightly either, and probably won't work until const-generics implementation improves).

[gnzlbg]

I don't know if this is the same issue that @eddyb mentioned here: #29646 (comment)

trait Foo { const A: usize; }
fn foo<F: Foo>(f: F) {
    const B: usize = F::A; // ERROR
    let b = F::A; // OK
}

[eddyb]

@gnzlbg Those are two items nested in eachother, we don't allow "inheriting" type parameters in such a situation and it'd be a significant language change to start doing that.
IOW, what you wrote is more or less equivalent to:

const __HIDDEN_B: usize = F::A;
fn foo<F: Foo>(f: F) {
    use self::__HIDDEN_B as B;
}

(and this is not in any way, shape, or form, specific to const or associated const)

[zpgaal]

Having const fn is this feature still required ? Of course it'd require to have const fn in traits as well.
(For now no array size can be given using either associated const or const fn)

((Or one could be the desugaring'of the other ))

[steveklabnik]

@zpgaal this feature is implemented and stable, so regardless of it being "required", it has to stay!

[vks]

@steveklabnik It seems like rustdoc does not generate documentation for associated constants in structs. Is this a bug?

[SimonSapin]

@vks I cannot reproduce this. rustdoc a.rs with the code below does document the constant.

pub struct Foo;

impl Foo {
    pub const BAR: u32 = 7;
}

[gnzlbg]

@SimonSapin I think the problem is:

pub struct Foo;

impl Foo {
    /// This doc comment won't be shown anywhere.
    pub const BAR: u32 = 7;
}

[SimonSapin]

Oh I see. Please file a bug separately?

[vks]

Oh I see. Please file a bug separately?

See #52260.