On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer wrote:
> On 5/23/18 9:12 AM, Steven Schveighoffer wrote:
>> On 5/22/18 9:59 PM, sarn wrote:
>
>>> (Unfortunately destroy() currently isn't zero-overhead for plain old data structs because it's based on RTTI, but at least it works.)
>> 
>> Hm.. that should be fixed. I don't see why we can't just do = T.init, we should at least be optimizing to this for small enough structs.
>
> Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178
>
>> Please file an enhancement request.
>
> I still think it could be better, so I added a further issue:
> https://issues.dlang.org/show_bug.cgi?id=18899
>
> -Steve

The destroy function for class/structs badly need an overhaul. Even more so for class, as (IMO) it should be responsibility of the class designer when it comes to deinitializing (The exception being that creating the class  exclusively for the GC to use of course), as finalize function which destroy calls is external, in which information such as attributes is lost

On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/22/18 10:15 PM, Manu wrote:
>>
>> If you're in the mood to prepare a DIP, I think you should prepare this dip:
>>
>> Support the syntax:
>>    classInstance.~this();
>
>
> Isn't this just classInstance.destroy() ?

Is everything in object.d globally available? You don't have to import
`destroy()` right?
My nit-pick is that destroy resets to .init after destruction, which
makes it feel like more than a destroy, and that is almost certainly
the reason people reach for __xdtor() when they do (ie, they JUST want
to destruct).
We should probably address that, and then publish a strong recommendation.

On Wednesday, May 23, 2018 17:29:11 12345swordy via Digitalmars-d wrote:
> On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer
>
> wrote:
> > On 5/23/18 9:12 AM, Steven Schveighoffer wrote:
> >> On 5/22/18 9:59 PM, sarn wrote:
> >>> (Unfortunately destroy() currently isn't zero-overhead for
> >>> plain old data structs because it's based on RTTI, but at
> >>> least it works.)
> >>
> >> Hm.. that should be fixed. I don't see why we can't just do = T.init, we should at least be optimizing to this for small enough structs.
> >
> > Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178
> >
> >> Please file an enhancement request.
> >
> > I still think it could be better, so I added a further issue: https://issues.dlang.org/show_bug.cgi?id=18899
> >
> > -Steve
>
> The destroy function for class/structs badly need an overhaul. Even more so for class, as (IMO) it should be responsibility of the class designer when it comes to deinitializing (The exception being that creating the class  exclusively for the GC to use of course), as finalize function which destroy calls is external, in which information such as attributes is lost

Regardless of what issues destroy may currently have, the entire reason that it exists is to destroy objects - and class objects in particular. So, if it doesn't currently work properly for that purpose, it needs to be fixed.

- Jonathan M Davis

On 5/23/18 1:41 PM, Manu wrote:
> On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On 5/22/18 10:15 PM, Manu wrote:
>>>
>>> If you're in the mood to prepare a DIP, I think you should prepare this
>>> dip:
>>>
>>> Support the syntax:
>>>     classInstance.~this();
>>
>>
>> Isn't this just classInstance.destroy() ?
> 
> Is everything in object.d globally available? You don't have to import
> `destroy()` right?
> My nit-pick is that destroy resets to .init after destruction, which
> makes it feel like more than a destroy, and that is almost certainly
> the reason people reach for __xdtor() when they do (ie, they JUST want
> to destruct).
> We should probably address that, and then publish a strong recommendation.
> 

I think it's a good idea. Like unsafeDestroy.

-Steve

On 5/23/18 1:41 PM, Manu wrote:
> Is everything in object.d globally available? You don't have to import
> `destroy()` right?

Oh, didn't answer this, yes object.d is always imported.

-Steve

On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote:
> On Wednesday, May 23, 2018 17:29:11 12345swordy via Digitalmars-d wrote:
>> On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer
>>
>> wrote:
>> > On 5/23/18 9:12 AM, Steven Schveighoffer wrote:
>> >> [...]
>> >
>> > Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178
>> >
>> >> [...]
>> >
>> > I still think it could be better, so I added a further issue: https://issues.dlang.org/show_bug.cgi?id=18899
>> >
>> > -Steve
>>
>> The destroy function for class/structs badly need an overhaul. Even more so for class, as (IMO) it should be responsibility of the class designer when it comes to deinitializing (The exception being that creating the class  exclusively for the GC to use of course), as finalize function which destroy calls is external, in which information such as attributes is lost
>
> Regardless of what issues destroy may currently have, the entire reason that it exists is to destroy objects - and class objects in particular. So, if it doesn't currently work properly for that purpose, it needs to be fixed.
>
> - Jonathan M Davis

Here is the thing though, when you call destroy on the object, you would assume by the name that the memory occupied by it will be deallocated which is NOT always the case. At this point I rather rename it as .deint, as it is less misleading here.

On Wednesday, May 23, 2018 18:04:28 12345swordy via Digitalmars-d wrote:
> On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote:
> > On Wednesday, May 23, 2018 17:29:11 12345swordy via
> >
> > Digitalmars-d wrote:
> >> On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >> > On 5/23/18 9:12 AM, Steven Schveighoffer wrote:
> >> >> [...]
> >> >
> >> > Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178
> >> >
> >> >> [...]
> >> >
> >> > I still think it could be better, so I added a further issue: https://issues.dlang.org/show_bug.cgi?id=18899
> >> >
> >> > -Steve
> >>
> >> The destroy function for class/structs badly need an overhaul. Even more so for class, as (IMO) it should be responsibility of the class designer when it comes to deinitializing (The exception being that creating the class  exclusively for the GC to use of course), as finalize function which destroy calls is external, in which information such as attributes is lost
> >
> > Regardless of what issues destroy may currently have, the entire reason that it exists is to destroy objects - and class objects in particular. So, if it doesn't currently work properly for that purpose, it needs to be fixed.
> >
> > - Jonathan M Davis
>
> Here is the thing though, when you call destroy on the object, you would assume by the name that the memory occupied by it will be deallocated which is NOT always the case. At this point I rather rename it as .deint, as it is less misleading here.

The documentation is quite clear that it does not free the memory, and it's never been the case that it was supposed to. And we already renamed it once from clear because of the problems that it caused with containers. At this point, I think that it would be overkill to rename it yet again, especially since we've been trying to not rename stuff unless we really need to, because it causes code breakage for what it usually minimal benefit.

- Jonathan M Davis

On Wednesday, 23 May 2018 at 18:11:45 UTC, Jonathan M Davis wrote:
> On Wednesday, May 23, 2018 18:04:28 12345swordy via Digitalmars-d wrote:
>> On Wednesday, 23 May 2018 at 17:47:12 UTC, Jonathan M Davis wrote:
>> > On Wednesday, May 23, 2018 17:29:11 12345swordy via
>> >
>> > Digitalmars-d wrote:
>> >> [...]
>> >
>> > Regardless of what issues destroy may currently have, the entire reason that it exists is to destroy objects - and class objects in particular. So, if it doesn't currently work properly for that purpose, it needs to be fixed.
>> >
>> > - Jonathan M Davis
>>
>> Here is the thing though, when you call destroy on the object, you would assume by the name that the memory occupied by it will be deallocated which is NOT always the case. At this point I rather rename it as .deint, as it is less misleading here.
>
> The documentation is quite clear that it does not free the memory, and it's never been the case that it was supposed to. And we already renamed it once from clear because of the problems that it caused with containers. At this point, I think that it would be overkill to rename it yet again, especially since we've been trying to not rename stuff unless we really need to, because it causes code breakage for what it usually minimal benefit.
>
> - Jonathan M Davis

My point being is that current objects rely on the external finalize function for de-inialtalzation, which is not ideal if you wanted to call destroy in the scope of system default attributes like @safe or @nogc. How do you think that the finalize function should behave in these contexts?

On 23 May 2018 at 10:59, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 5/23/18 1:41 PM, Manu wrote:
>>
>> On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On 5/22/18 10:15 PM, Manu wrote:
>>>>
>>>>
>>>> If you're in the mood to prepare a DIP, I think you should prepare this dip:
>>>>
>>>> Support the syntax:
>>>>     classInstance.~this();
>>>
>>>
>>>
>>> Isn't this just classInstance.destroy() ?
>>
>>
>> Is everything in object.d globally available? You don't have to import
>> `destroy()` right?
>> My nit-pick is that destroy resets to .init after destruction, which
>> makes it feel like more than a destroy, and that is almost certainly
>> the reason people reach for __xdtor() when they do (ie, they JUST want
>> to destruct).
>> We should probably address that, and then publish a strong recommendation.
>>
>
> I think it's a good idea. Like unsafeDestroy.

I hate the name.
People will constantly reach for the wrong thing.
Such a long name says to me "this isn't the function you're looking
for" in terms of intuition.

For my money it would be:
destroy() <- just destroy
reset() <- destroy and re-init

Or something like that.

Maybe:
class.destruct(); <- destroy without init?

Yeah that. I'll make a PR!

On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote:
> The one other usage of these low-level destructor facilities is checking if a type is a plain old data struct.  This is an important special case for some code, but everyone seems to do the check a different way.  Maybe a special isPod trait is needed.

There's this:

https://dlang.org/spec/traits.html#isPOD