Efficient single inheritance

Efficient single inheritance via virtual structs and unification and nesting of structs and enums.
+1
2014年6月28日 上午3:54于 "pepp-cz" <notifications@github.com>写道：

> In 0000-virtual.md:
>
> > +Non-leaf struct values are unsized, that is they follow the rules for DSTs. You
> > +cannot use non-leaf structs as value types, only pointers to such types. E.g.,
> > +(given the definition of `S1` above) one can write `x: S2` (since it is a leaf
> > +struct), `x: &S2`, and `x: &S1`, but not `x: S1`. Struct values have their
> > +minimal size (i.e., their size does not take into account other variants). This
> > +is also current behaviour. Pointers to structs are DST pointers, but are not
> > +fat. They point to a pointer to a vtable, followed by the data in the struct.
> > +The vtable pointer allows identification of the struct variant.
> > +
> > +To summarise the important differences between enums and structs: enum objects
> > +may be passed by value where an outer enum type is expected. Struct objects may
> > +only be passed by reference (borrowed reference, or any kind of smart or built-
> > +in pointer). enum values have the size of the largest variant plus a
> > +discriminator (modulo optimisation). Struct values have their minimal size. For
> > +example,
> > +
>
> @bstrie <https://github.com/bstrie> Swift may be fifth-most-popular
> because of strong backing by Apple and because it is targeted on different
> kind of applications than Rust is. Rust is low-level language and user
> should have maximum control on everything. Also user should pay only for
> features he needs. Different behaviour for structs and classes is IMO a bad
> feature that Swift has got and definitely something what should not be
> copied to Rust.
>
> Why?
> 1) It dictates the user of the a type how it must be created. You cannot
> have Swift's class by-value on a stack, ever. You pay what you do not need.
> Personally, I would be very disappointed to find out that a Rust library
> declares a simple type as a struct and therefore I am forced to allocate it
> on heap.
>
> 2) It is not clear when the parameter is passed by value or ref by looking
> at a function call or a function definition. It can be source of naughty
> bugs where you alter only local copy by accident. However, there is
> probably no way how would Rust share this weakness with Swift as structs
> would be still explicitly boxed.
>
> 3) Rust has polymorphism system orthogonal to types, yet this proposal
> ties polymorphism to type hierarchy. A struct would be suited to one
> particular polymorphic data-structure but not to any other. You have to
> build type-hierarchy for every data-structure from the ground.
>
> The proposal #9 <https://github.com/rust-lang/rfcs/pull/9> it is strictly
> superior solution.
> 1) You can create any struct or enum on the stack, heap or turn it into
> fat object if you want to.
> 3) You can turn even int or float to a fat object, and you can do that for
> different traits on different places. You can mix completely independent
> types in a polymorphic collection. You have the freedom to do that anywhere
> and yet you have the power to do that for every type. And it completely
> independent from inheritance which you may or may not use.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/rust-lang/rfcs/pull/142/files#r14312029>.
>