Use the `destroy` function to finalize an object by calling its destructor. The memory of the object is not immediately deallocated, instead the GC will collect the memory of the object at an undetermined point after finalization:

class Foo { int x; this() { x = 1; } }
Foo foo = new Foo;
destroy(foo);
assert(foo.x == int.init);  // object is still accessible


But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it?

On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
> But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it?

`destroy` is mainly about running destructors deterministically. From the source comments:

> "It's used to destroy an object so that any cleanup which its destructor or finalizer does is done and so that it no longer references any other objects."

For example, your object might allocate a large amount of manually-managed memory, and you don't want that allocation laying around until the next GC cycle, so you can use `destroy` to finalise your object as early as possible to release that manually-managed allocation.

If you really want to deallocate the object's own memory, you can check out core.memory.GC.query() / core.memory.GC.free().

On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
> But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it?

You should call destroy when you want to call the destructor deterministically, see https://en.wikipedia.org/wiki/Resource_management_%28computing%29 - compare with automatic resource management.

On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
> Use the `destroy` function to finalize an object by calling its destructor. The memory of the object is not immediately deallocated, instead the GC will collect the memory of the object at an undetermined point after finalization:
>
> class Foo { int x; this() { x = 1; } }
> Foo foo = new Foo;
> destroy(foo);
> assert(foo.x == int.init);  // object is still accessible
>
>
> But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it?

Destroy will call the destructors, but memory will not actually be deallocated before the next GC cycle. It is used because the GC cycle does not guarantee to run the destructors, so using destroy the destructor is ran immediately (guaranteed). Then, on next GC iteration, the memory will be freed. Until then, referencing it will not cause segfault, but will cause undefined behaviour, as after a destructor the state of the object is undefined (I think).

On Friday, July 29, 2016 13:18:00 Suliman via Digitalmars-d-learn wrote:
> Use the `destroy` function to finalize an object by calling its destructor. The memory of the object is not immediately deallocated, instead the GC will collect the memory of the object at an undetermined point after finalization:
>
> class Foo { int x; this() { x = 1; } }
> Foo foo = new Foo;
> destroy(foo);
> assert(foo.x == int.init);  // object is still accessible
>
>
> But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it?

destroy is for when you need to explicitly call the destructor on an object. It destroys it without freeing the memory. There are some rare cases where that is extremely useful, but odds are, you'll never need it.

- Jonathan M Davis