Direct access to struct construction, copying and destruction

[Benjamin Thaut]

Am 09.07.2012 19:36, schrieb 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
>

Clear uses the TypeInfo. The proposed functions should not be library 
functions but directly aviable from the compiler. Something like 
__postblit and __dtor but properly implemented.

Kind Regards
Benjamin Thaut