[Issue 14912] Move initialisation of GC'd struct and class data from the callee to the caller

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Fri Aug 14 14:32:24 PDT 2015


https://issues.dlang.org/show_bug.cgi?id=14912

--- Comment #12 from Iain Buclaw <ibuclaw at gdcproject.org> ---
(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.

--


More information about the Digitalmars-d-bugs mailing list