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