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

Felix S. Klock II pnkfelix at mozilla.com
Thu Jul 17 10:04:20 PDT 2014


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 <thesaint1987 at googlemail.com> 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 <sfackler at gmail.com> 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 <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
> 
> _______________________________________________
> 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/20140717/aba3faf8/attachment.html>


More information about the Rust-dev mailing list