We have considered the option of struct inheritance, and in that design we included the option of a trait being limited to types that extend a struct. This creates a less general trait, similar to what happens in Java is you specify an abstract interface in terms of a class rather than an interface. The primary motivation for this feature is efficiency. Access to those fields, even if it it occurs through a trait object, would be simple and efficient (whereas accessors are virtual method calls). As far as I know this is still "on the table" but will not be implemented in the short term.
What you propose sounds somewhat different. It sounds like you are suggesting adding fields fields to a trait definition and then, I suppose, permitting the `impl` to map the field to a pair of accessors? We've never considered this, but it seems like a lot of complexity for relatively little benefit, since the generated code would not be more efficient than today. Perhaps it might be done as part of general support for property accessors, but that won't come for some time if ever. You could also say that impls must map the trait fields to other fields within the impl'ing type. That would be a middle-ground, since the offset would not be statically known when using a trait object, but you would at least know that there is some offset and just load that, rather than using a full method call. Still I think the complexity-performance-gain tradeoff doesn't feel high enough. Niko On Fri, Sep 20, 2013 at 08:02:01AM -0300, Andres Osinski wrote: > Hi all, I have a question which I'm sure must have already been discussed > and dealt with, but I wanted to understand the design rationale: > > A lot of trait-level functionality would be enhanced if a trait could > specify members to be included in the struct which implements the trait. > This can be solved in practice by wrapping member access in accessor > methods, but I fail to see why that would be preferable. > > The reason I'm asking is because I'm trying to design data structures which > contain a couple of arrays, and I wanted to define the trait by not only a > set of supported operations but by the existence of both arrays so that a > default method could deal with any struct which implements the trait, > instead of having to define for every struct an accessor method for each > structure and then have to call the accessors in the trait to do anything. > > Thanks > > -- > Andrés Osinski > http://www.andresosinski.com.ar/ > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
