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.

Kind Regards
Benjamin Thaut

No one has a opinion on this?

On 07/09/2012 06:15 PM, Benjamin Thaut wrote:
> No one has a opinion on this?

The features should obviously be exposed. I was astonished that
__postblit does not work if there is no explicit postblit defined.

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

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

On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
> 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.

Well, since all of the necessary information is in the TypeInfo, not in the type itself, I don't see how you're going to do that. As I understand it, it's not the compiler that deals with all of that. It's druntime. So, without a major redesign, there's no way that the compiler is going to generate that stuff for you. That's druntime's job.

- Jonathan M Davis

Am 10.07.2012 00:53, schrieb Jonathan M Davis:
> On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
>> 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.
>
> Well, since all of the necessary information is in the TypeInfo, not in the
> type itself, I don't see how you're going to do that. As I understand it, it's
> not the compiler that deals with all of that. It's druntime. So, without a
> major redesign, there's no way that the compiler is going to generate that
> stuff for you. That's druntime's job.
>
> - Jonathan M Davis
>

So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

Kind Regards
Benjamin Thaut

On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
> Am 10.07.2012 00:53, schrieb Jonathan M Davis:
> > On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
> >> 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.
> > 
> > Well, since all of the necessary information is in the TypeInfo, not in
> > the
> > type itself, I don't see how you're going to do that. As I understand it,
> > it's not the compiler that deals with all of that. It's druntime. So,
> > without a major redesign, there's no way that the compiler is going to
> > generate that stuff for you. That's druntime's job.
> > 
> > - Jonathan M Davis
> 
> So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.

I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime.

- Jonathan M Davis

Am 10.07.2012 07:13, schrieb Jonathan M Davis:
> On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
>> Am 10.07.2012 00:53, schrieb Jonathan M Davis:
>>> On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
>>>> 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.
>>>
>>> Well, since all of the necessary information is in the TypeInfo, not in
>>> the
>>> type itself, I don't see how you're going to do that. As I understand it,
>>> it's not the compiler that deals with all of that. It's druntime. So,
>>> without a major redesign, there's no way that the compiler is going to
>>> generate that stuff for you. That's druntime's job.
>>>
>>> - Jonathan M Davis
>>
>> So who fills the TypeInfo objects, the runtime? I always assumed that
>> the compiler fills the TypeInfo and therefor has all the neccessary
>> information already at hand.
>
> I don't know the details, but as I understand it, all of the logic for
> actually copying and destroying things properly is in druntime. The compiler
> doesn't do any of that. That being the case, any code which wants to use a
> type's postblit or destructor needs to use druntime. Right now, I believe that
> the compiler just uses hooks into the druntime code like it does with stuff
> like new and AAs. So, to skip using the druntime functions to properly copy or
> destroy an object, the compiler would have to duplicate the logic which
> currently resides in druntime.
>
> - Jonathan M Davis
>

Thats fine, I don't want the compiler to duplicate that logic. I just want the compiler to expose all the neccessary function that are provided by the compiler anyway so *I* can duplicate the logic from D-Runtime *without* going over a TypeInfo Object.

Kind Regards
Benjamin Thaut

On Wednesday, July 11, 2012 09:28:15 Benjamin Thaut wrote:
> Am 10.07.2012 07:13, schrieb Jonathan M Davis:
> > On Tuesday, July 10, 2012 06:53:29 Benjamin Thaut wrote:
> >> Am 10.07.2012 00:53, schrieb Jonathan M Davis:
> >>> On Monday, July 09, 2012 22:41:57 Benjamin Thaut wrote:
> >>>> 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.
> >>> 
> >>> Well, since all of the necessary information is in the TypeInfo, not in
> >>> the
> >>> type itself, I don't see how you're going to do that. As I understand
> >>> it,
> >>> it's not the compiler that deals with all of that. It's druntime. So,
> >>> without a major redesign, there's no way that the compiler is going to
> >>> generate that stuff for you. That's druntime's job.
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> So who fills the TypeInfo objects, the runtime? I always assumed that the compiler fills the TypeInfo and therefor has all the neccessary information already at hand.
> > 
> > I don't know the details, but as I understand it, all of the logic for actually copying and destroying things properly is in druntime. The compiler doesn't do any of that. That being the case, any code which wants to use a type's postblit or destructor needs to use druntime. Right now, I believe that the compiler just uses hooks into the druntime code like it does with stuff like new and AAs. So, to skip using the druntime functions to properly copy or destroy an object, the compiler would have to duplicate the logic which currently resides in druntime.
> > 
> > - Jonathan M Davis
> 
> Thats fine, I don't want the compiler to duplicate that logic. I just want the compiler to expose all the neccessary function that are provided by the compiler anyway so *I* can duplicate the logic from D-Runtime *without* going over a TypeInfo Object.

Then look over TypeInfo and see what it does. It may be possible to just duplicate what it's doing. I don't know. Certainly, TypeInfo is used by druntime to do the postblits and destructors, so even the compiler is using TypeInfo for doing that.

- Jonathan M Davis