D's Destructors are What Scott Meyers Warned Us About

[Jonathan M Davis]

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