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

--- Comment #11 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(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.

--

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

--- Comment #12 from Iain Buclaw <ibuclaw@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.

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |performance
                 CC|                            |bugzilla@digitalmars.com

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=24368

--