On 2014-04-17, at 11:25, Marvin Löbel <loebel.mar...@gmail.com> wrote:
> Would you mind me taking this RFC over and including it into my proposal? Yes please, by all means. I'm looking forward to your proposal. But actually I just realized that my proposal is essentially just a syntax sugar for a macro producing boiler-plate code. That imaginary macro simply copy pastes the provided method defined in the trait to the trait implementation and replaces each use of an expected field with the actual field that's mapped to it. So, in some sense you could simply think of my example 1 (the one with the imaginary syntax) translating to this (actual Rust code): trait Unify<T: Clone> { fn unify(&mut self); } struct Stuff { a: u32, b: u32 } impl Unify<u32> for Stuff { fn unify(&mut self) { self.b = self.a.clone(); } } And here's that example 1 again for completeness sake: trait Unify<T: Clone> { Self { x: T, y: T } fn unify(&mut self) { self.y = self.x.clone(); } } struct Stuff { a: u32, b: u32 } impl Unify<u32> for Stuff { Stuff { x => a, y => b } } But a small and important detail about the compiler implementation is that if there are multiple types that implement Unify<u32> with the exactly same field offsets for the expected fields, then the compiler can compile the function Unify<u32>::unify for those types just once and use the same function for each type. A simple textual macro with a search & replace is very easy to reason about.
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev