simen.kjaras at gmail.com
Sun Oct 24 14:41:07 PDT 2010
spir <denis.spir at gmail.com> wrote:
> I would like to learn about possible workarounds, or other alternative
> approaches to such problems, if ever you now any.
Basically, you probably want to use alias this:
It lets you subtype structs by propagating member field/function access
to a member, if the struct or class does not implement the field or
alias this is panacea - if a function expects a base struct, and returns
it after doing some alterations, you cannot cast the result to a subtype
> Also, I would love to read about the rationale for _not_ having struct
> type hierarchies (probably this would not be a big deal, since D has it
> for classes (*)) Or maybe I have simply not correctly understood
> available docs?
The main reason is the slicing problem. If the language lets a user store
a struct that is a subtype of another struct, and that adds fields, in a
location where space is only allocated for the base struct, the extra
fields are eaten by grues, and bugs appear.
More information about the Digitalmars-d-learn