Associated constants should not be object safe

[ftxqxd]

The following code compiles:

#![feature(associated_consts)]

trait Foo {
    const FOO: u32;
}

impl Foo for () {
    const FOO: u32 = 1;
}

fn main() {
    let _: &Foo = &();
}

Furthermore, adding the line <Foo>::FOO; to main causes an ICE:

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'assertion failed: match trait_items[method_offset_in_trait] {
    ty::MethodTraitItem(_) => true,
    _ => false,
}', ../src/librustc/middle/traits/util.rs:439

[oli-obk]

I think the code should be legal to compile. It's impossible to get the value of FOO from a variable (there's no such thing as a::FOO where a is a binding of type &Foo).

[arielb1]

@oli-obk
Well it shouldn't compile

[brson]

I don't know if this can lead to unsoundness or not. Correct me.

[brson]

@eddyb says no

[withoutboats]

Update on this, the example in the original post compiles today.

But this ICEs:

#![feature(associated_consts)]

trait Foo {
    const FOO: u32;
}

impl Foo for () {
    const FOO: u32 = 1;
}

fn main() {
    let _ = <Foo as Foo>::FOO;
}

AFAICT there are two options here:

1. Associated consts are not object safe, just like associated (static) functions.
2. Associated consts must all be specified, just like associated types.

I think its sensible to start with the first. The second makes more sense in the context of a world with const params, but the first can be extended to the second.

It might also make sense some day to allow where clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).

[withoutboats]

#41494

[gnzlbg]

Can't associated consts be part of the vtable/fat pointers?

[withoutboats]

Associated consts are inlined at compiletime, they can't have a value which is determined at runtime. This is a hard requirement for making things like const fn and const generics work.

Associated statics could be object safe if they existed.

[gnzlbg]

I think that having to write:

trait Foo {
    fn get_x(&self) -> u32;
}

trait FooC {
    const X: u32;
}

impl FooC for () {
    const X: u32 = 3;
}

impl Foo for () {
    fn get_x(&self) -> u32 { <() as FooC>::X } ; // or just 3
}

instead of just:

trait Foo {
  const X: u32;
}

or

trait Foo {
  const X: u32;
  fn get_x(&self) -> u32 { Self::X } 
}

is a pain.

they can't have a value which is determined at runtime.

The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.

[withoutboats]

The value is not determined at compile time for the virtually dispatched type Foo (the trait object type). What you want is the fields in traits RFC.

[gnzlbg]

The value is not determined at compile time for the virtually dispatched type Foo (the trait object type).

I did not say otherwise (the value is only determined at compile-time for the types that implement Foo, not for Foo itself or trait objects). What I did say is that currently there is no way to access this value at run-time without in my opinion unnecessary boilerplate but there should be one.

[gnzlbg]

Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).

[nyovaya]

Will they be object-safe in the future?
I mean if "fn foo() -> u8 where Self: Sized;" is already safe why are consts not?