AFAIK the go solution walks a thin line here. An anonymous field means one
can directly access any subfield, and also that the container has all the
included struct traits - as implemented by the included struct. It is also
possible to override the implementation.

This is different from what was asked which was the opposite - the go way
is the struct implies the trait, what was asked was that the trait implies
the struct.

I think the go approach makes a lot of sense - I found it to need very
useful and simple (e.g. ambiguities are not allowed). The go docs have a
better description - give it a look...
On Sep 20, 2013 11:30 PM, "Tobias Müller" <[email protected]> wrote:

> Andres Osinski <[email protected]>
> 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.
>
> IMO this would completely defeat the  advantage of traits over inheritance
> based interfaces.
>
> The beauty of traits is, that the trait and the type are separated, only
> connected by the implementation:
> - You can add an implementation for your custom trait to any existing type.
> - You can add an implementation for any existing trait to your custom type.
>
> Now if you add a fields specification to the trait, the former isn't true
> anymore. The type has now a dependency on the trait since it must at least
> contain a field of a given type, if not even with a given name.
>
> If you the concrete type is under your control, this is obviously not a
> problem, as it is the case with inheritance based interfaces. But you
> cannot simply assume that for every use case.
>
> Tobi
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to