Feature idea: New way to use impl for to reduce code duplication

I don't really know how to get my point across effectively, so I'm going to present you with examples.

Look at this:

trait SuperCoolTrait {
  fn myFunction(&self);
}

// Implementing the type itself
impl MyType {
  fn function() {
    unimplemented!()
  }
}

// Implementing trait for the type

// Duplicating the type's name name, lots of extra
// and unnecessary typing
impl SuperCoolTrait for MyType {
  fn myFunction(&self) {
    unimplemented!()
  }
}

and then compare that to something like this

trait SuperCoolTrait {
  // --snip--
}

impl MyType with SuperCoolTrait {
  fn function() {
    unimplemented!()
  }

  // SuperCoolTrait
  fn myFunction(&self) {
    unimplemented!()
  }
}

This shorthand just looks much cleaner (in my personal opinion), duplicates names less (if you are renaming a struct, that is one less place(s?) to rename). An even shorter shorthand would be to put the struct's functions directly inside of it... and why Rust's designers didn't do that I don't know (and maybe you can help me find out :slight_smile:). I imagine it would look something like this:

// Instead of renaming twice, you only have to do it once! (For the struct's declarations)

// P.S: Me using struct does not mean that this is necessarily exclusive to structs.
struct MyType with SuperCoolTrait {
  // Semicolon instead of comma?
  field: Foo;
  fn function() {
    unimplemented!();
  }
  fn myFunction(&self) {
    unimplemented!();
  }
}

I want to know what you guys think of such a design and if you have anything to add to the conversation.

It doesn't. Basically every other mainstream language does it like you proposed, and it drives me nuts, not being able to tell which function comes from the type and which one from a trait. Furthermore, this would be ambiguous if a type contained an inherent method with the same signature as a trait method. The status quo is much better for code clarity — we read code disproportionately more than we write it, so we shouldn't optimize for writing at the cost of readability.

Anyway, feature proposals are off-topic here, their proper place is IRLO.

5 Likes

For anyone who doesn’t know the acronym, it’s https://internals.rust-lang.org/

5 Likes

Hmm... good proposal. Maybe they syntax could be restructured?

Anyways, I am relocating this thread now. Thanks for the info.

I think the diference is that "other languages" dont have traits, so they are in a difference situation. But in rust where the method is attached to a specific trait it really doesnt read well.

If rust had a diferent trait system this might work much better.

I think it's telling that languages that worked this way, like Java, eventually grew an @Override annotation that explicitly marks what methods come from the trait. In that sense, Rust is doing what Java wanted to do all along :wink:

And from those languages, we know another problem – what if two traits define a method of the same name?

5 Likes

This topic was automatically closed 7 days after the last reply. We invite you to open a new topic if you have further questions or comments.