Note that we are well aware that the issue Christoph mentioned is a wart for some uses of traits. E.g. some trait implementors really would like to be told when they missed a method because it has a default implementation already.
One way to resolve this would be a lint; that has been previously filed as Issue #14220: "add attribute on impl and associated lint for "no default methods" https://github.com/rust-lang/rust/issues/14220 Cheers, -Felix On 16 Jul 2014, at 21:16, Christoph Husse <[email protected]> wrote: > doh. okay. it has a lot to do with it but it is enabled by default then :D. > slowly climbing the learning curve lol > > On Wednesday, July 16, 2014, Steven Fackler <[email protected]> wrote: > I don't see what this has to do with @Override. @Override causes the compiler > to check to make sure that the method signature matches a supertype method. > Rust always enforces that check inside of a trait implementation block. This > kind of thing is always illegal: > > impl SomeTrait for Foo { > fn some_random_method_that_isnt_part_of_some_trait(&self) { ... } > } > > The visitor trait is huge, and 99% of use cases don't need to visit every > possible part of the AST, so there are default implementations of all of the > methods that simply fall through to visit all of the subparts. That comment > is just saying that if you *do* want to visit everything, you have to > manually check to make sure you're overriding everything. > > Steven Fackler > > > On Wed, Jul 16, 2014 at 11:59 AM, Christoph Husse > <[email protected]> wrote: > This comment from "syntax::visit::Visitor" really gives me a headache: > > /// If you want to ensure that your code handles every variant > /// explicitly, you need to override each method. (And you also need > /// to monitor future changes to `Visitor` in case a new method with a > /// new default implementation gets introduced.) > > I kindof thought we would have passed this :(. > "I" need to check for future changes :O? How? Closed source 3rd party, > just to name one example, or simply oversight. Okay, an IDE could warn > too. But we dont' have one right now and in the past it didn't seem > like this would have helped much. > > What's the rationale behind this decision? > > Why no: #[Impl] attribute or something? > > Sry, if I bring up old discussions but it was kinda hard to come up > with a search term for this. > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
