Direct access to struct construction, copying and destruction

[Jonathan M Davis]

On Sunday, July 08, 2012 15:23:41 Benjamin Thaut wrote:
> While writing certain parts of my own little standard library
> (containers etc) I had to notice that D has a overcomplicated way of
> especially postblitting and destructing structs. By overcomplicated I
> mean that you don't have any other choice but to go through a TypeInfo
> object to the process correctly.
> 
> Postblitting:
> If the struct has a postblit constructor you can directly call
> __postblit but if it does not have one, you have to go over the TypeInfo
> object to call __fieldPostBlit which is not directly exposed.
> 
> Destruction:
> Pretty mutch the same situation as for postblitting. If it has a own
> destructor you can call __dtor, but if not you have to use the typeinfo
> object to call the destructor because the appropirate destructor is not
> directly exposed.
> 
> I find this strange because having to go through a TypeInfo object,
> which is a lot of unneccessary indirections for calling a function that
> is known at compile time and could even be inlined if it would be called
> directly, seems totaly overkill to me.
> 
> I would find it extremly usefull for low level code (unsafe of course)
> to have 3 simple functions that do the following:
> 
> cpctor: if present struct needs to be copy constructed, always calls the
> correct copy constructor
> 
> postblit: if present the struct needs to be postblit constructed, calls
> __postblit if the struct has a own postblit constructor, otherwise it
> calls __fieldPostBlit
> 
> dtor: if present the struct needs to be destructed. Calls the
> appropriate destructor.
> 
> This would give a better low level control over struct construction and
> destruction and would allow compilers to inline the functions if
> appropriate.
> 
> If some or all of the above is wrong, I'm going to look forward to
> beeing corrected.

For destruction, I believe that clear (or destroy on git master) takes care of 
it, but the rest of it is definitely a problem - though since all of that 
information lives in TypeInfo, I'd expect your three proposed functions to 
just be using TypeInfo, which doesn't really help your complaint about 
indirections (though the compiler may still have enough information there to 
be able to inline appropriately).

- Jonathan M Davis