[rust-dev] Why no "@Override" analogy?

Steven Fackler sfackler at gmail.com
Wed Jul 16 12:08:09 PDT 2014

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 <
thesaint1987 at googlemail.com> 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
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140716/b42d6c69/attachment.html>

More information about the Rust-dev mailing list