On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer
wrote:
The GC still needs to call something to clean up non-memory
resources,
Well, I'd much prefer if the GC would simply not call
destructors. Yes, destructor can work for _some_ resources, but
because of ordering it also create accidental correctness, or
just doesn't work with other resources.
but having a call to use when cleaning up deterministically can
make resource management more efficient (even memory resource
management).
Yes. My point is that the destructor is uniquely positionned to
be that call.
(This would also enables back failing destructors through the use
of exceptions.)
In current D the problem with allowing the GC to close resources
is that there is no ordering of destructors. A sub-tree of the
ownership graph is freed by the GC together, but sometime an
order is required for releasing.
Typically: you want to release a SDL_Texture but the Derelict
SharedLib object has been freed already, so you can't call
sdl_releaseTexture. It doesn't matter that the texture object
held a reference to the ShareLib object since the sub-tree is
destroyed together. close() methods don't help with that, the
problem is with the GC calling destructors.
And if _some_ resource needs an ordering, then this property leak
on their owners, so little by little the whole ownership graph
need determinism.
