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?
