Change:
The following code compiles: Furthermore, adding the line to causes an ICE:
I think the code should be legal to compile. It's impossible to get the value of from a variable (there's no such thing as where is a binding of type ).
Well it shouldn't compile
I don't know if this can lead to unsoundness or not. Correct me.
says no
Update on this, the example in the original post compiles today. But this ICEs: AFAICT there are two options here: consts are not object safe, just like associated (static) functions. 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 clauses on associated consts just like methods (and on associated types, for that matter, which connects in some degree with the ATC RFC).
Can't associated consts be part of the vtable/fat pointers?
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.
I think that having to write: instead of just: or is a pain. The value is determined at compile-time, but I am talking about being able to access that value at run-time via dynamic dispatch.
The value is not determined at compile time for the virtually dispatched type (the trait object type). What you want is the fields in traits RFC.
I did not say otherwise (the value is only determined at compile-time for the types that implement , not for 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.
Maybe the problem is that traits support associated consts, and associated consts are values, but traits do not support associated values (yet).
Will they be object-safe in the future? I mean if "fn foo() -u8 where Self: Sized;" is already safe why are consts not?

Discussion:
/// Method has something illegal Method(ast::Name, MethodViolationCode), <ins> /// Associated const AssociatedConst(ast::Name), </ins> } impl ObjectSafetyViolation {

in its arguments or return type", name).into(), ObjectSafetyViolation::Method(name, MethodViolationCode::Generic) => format!("method `{}` has generic type parameters", name).into(), <ins> ObjectSafetyViolation::AssociatedConst(name) => format!("the trait cannot contain associated consts like `{}`", name).into(), </ins> } } }

violations.push(ObjectSafetyViolation::SupertraitSelf); } <ins> violations.extend(self.associated_items(trait_def_id) .filter(|item| item.kind == ty::AssociatedKind::Const) .map(|item| ObjectSafetyViolation::AssociatedConst(item.name))); </ins> debug!("object_safety_violations_for_trait(trait_def_id={:?}) = {:?}", trait_def_id, violations);

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Check that we correctly prevent users from making trait objects // from traits with associated consts. #![feature(associated_consts)] trait Bar { const X: usize; } fn make_bar<T:Bar>(t: &T) -> &Bar { //~^ ERROR E0038 //~| NOTE the trait cannot contain associated consts like `X` //~| NOTE the trait `Bar` cannot be made into an object t } fn main() { } </ins>