Change:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.

Discussion:
sp: Span) { // Merges the module with the existing type def or creates a new one. let modifiers = if is_public { PUBLIC } else { DefModifiers::empty() } | IMPORTABLE; <del> let module_ = Rc::new(Module::new(parent_link, def_id, kind, external, </del> <ins> let module_ = Rc::new(Module::new(parent_link, def_id, kind, external, </ins> is_public)); let type_def = self.type_def.borrow().clone(); match type_def {

// Create the module and add all methods. match ty.node { TyPath(ref path, _, _) if path.segments.len() == 1 => { <ins> // FIXME(18446) we should distinguish between the name of // a trait and the name of an impl of that trait. </ins> let mod_name = path.segments.last().unwrap().identifier.name; let parent_opt = parent.module().children.borrow()

// It already exists Some(ref child) if child.get_module_if_available() .is_some() && <del> child.get_module().kind.get() == ImplModuleKind => { </del> <ins> (child.get_module().kind.get() == ImplModuleKind || child.get_module().kind.get() == TraitModuleKind) => { </ins> ModuleReducedGraphParent(child.get_module()) } Some(ref child) if child.get_module_if_available()

// and `Rc<Baz>`. (Note that it is not a *coherence violation* // to have impls for both `Bar` and `Baz`, despite this // ambiguity).  In this case, we report an error, listing all <del> // the applicable impls.  The use can explicitly "up-coerce" </del> <ins> // the applicable impls.  The user can explicitly "up-coerce" </ins> // to the type they want. // // Note that this coercion step only considers actual impls

fn all_impls(&self, trait_def_id: ast::DefId) -> Vec<ast::DefId> { /*! <del> * Returns se tof all impls for a given trait. </del> <ins> * Returns set of all impls for a given trait. </ins> */ ty::populate_implementations_for_trait_if_necessary(self.tcx(),

let impl_items = self.create_impl_from_item(item); for associated_trait in associated_traits.iter() { <del> let trait_ref = ty::node_id_to_trait_ref( self.crate_context.tcx, associated_trait.ref_id); </del> <ins> let trait_ref = ty::node_id_to_trait_ref(self.crate_context.tcx, associated_trait.ref_id); </ins> debug!("(checking implementation) adding impl for trait '{}', item '{}'", trait_ref.repr(self.crate_context.tcx), token::get_ident(item.ident));

let self_ty = ty::lookup_item_type(self.tcx, def_id).ty; match ty::get(self_ty).sty { ty::ty_enum(def_id, _) | <del> ty::ty_struct(def_id, _) => { </del> <ins> ty::ty_struct(def_id, _) | ty::ty_trait(box ty::TyTrait{ def_id, ..}) => { </ins> if def_id.krate != ast::LOCAL_CRATE { span_err!(self.tcx.sess, item.span, E0116, "cannot associate methods with a type outside the 

<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. // Test calling methods on an impl for a bare trait. This test checks that the // trait impl is only applied to a trait object, not concrete types which implement // the trait. trait T {} impl<'a> T+'a { fn foo(&self) {} } impl T for int {} fn main() { let x = &42i; x.foo(); //~ERROR: type `&int` does not implement any method in scope named `foo` } </ins>

<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. // Test calling methods on an impl for a bare trait. This test checks trait impls // must be in the same module as the trait. mod Foo { trait T {} } mod Bar { impl<'a> ::Foo::T+'a { //~ERROR: inherent implementations may only be implemented in the same fn foo(&self) {} } } fn main() {} </ins>

<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. // Test calling methods on an impl for a bare trait. static mut COUNT: uint = 1; trait T {} impl<'a> T+'a { fn foo(&self) { unsafe { COUNT *= 2; } } fn bar() { unsafe { COUNT *= 3; } } } impl T for int {} fn main() { let x: &T = &42i; x.foo(); T::foo(x); T::bar(); unsafe { assert!(COUNT == 12); } } </ins>