`#[no_override]` for default methods

[huonw]

If there was a #[no_override] attribute that made it impossible to override a default method, there would be very little need for the FooUtil traits (with this attribute default methods would have almost exactly the same properties as *Util, except the seperate trait can be imported separately). i.e.

trait Foo {
  fn bar(&self);

  #[no_override]
  fn call_bar(&self) { self.bar(); }
}
impl Foo for int {
  fn bar(&self) {}

  fn call_bar(&self) {} // error!
}

This would provide a workaround for #5898 that is a proper solution in its own right.

[metajack]

This probably warrants some discussion on the mailing list or in a meeting. We need some kind of decision before we can take action here.

[sanxiyn]

Triage. Tagging RFC.

[sfackler]

I think the current situation needs some work, even if it only affects rustdoc output. We have some very common traits like Writer and Iterator that have a couple of required methods and a huge number of default methods one of which should sometimes be overridden (e.g. Writer::flush and Iterator::size_hint). The fact that those methods, as opposed to any others are supposed to be overridden is exceptionally undiscoverable from looking at the rustdoc for the traits, IMO.

I think there's probably cases where it would be appropriate to override things like read_be_i32 or flat_map so I wouldn't want to forbid overriding, but some annotation that would cause rustdoc to split the definitions into Default Methods and Extension Methods (or something) would help.

[sanxiyn]

Any update here?

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#291