https://issues.dlang.org/show_bug.cgi?id=14912
--- Comment #12 from Iain Buclaw <[email protected]> --- (In reply to Steven Schveighoffer from comment #11) > (In reply to Iain Buclaw from comment #9) > > > > Still need the ability to *deref a class to assign in bulk to its underlying > > structure in the language. Currently only the compiler/codegen is allowed > > to do that. > > We can do tupleof right now, but it just doesn't include the vtable and > monitor. That is easily figured out via casting. > > (In reply to Iain Buclaw from comment #10) > > And I read "from the compiler is the components that make up the ci.init" as > > a proposal for adding yet another property. > > At the moment, we already HAVE that via some magic compiler knowledge of the > TypeInfo_Class object (where it stashes the ci.init). If we remove the > compiler knowledge of this, and expose the c.init via a __traits for > instance, then we have all we need to build the runtime in a way that is > expandable, customizable, and optimizable. > > I really think the future includes a completely druntime-generated druntime, > based on compile-time introspection. > > It may be this is too far off in the distance, and perhaps we could put more > magic in the compiler now to save a bit of performance, but I'd rather wait > until we do it right, and not add any *more* magic there. Just my opinion. There's nothing really to add because the compiler already does this - see initialization of classes that supply their own new operator, for instance. And I wouldn't call it magic, infact I'd say that it's always expected that the compiler should initialize at least the vtable (C++ for instance), rather than inventing some trait that allows the user a gateway to initialize hidden immutable data with anything they wish. --
