| |
| Posted by Tejas in reply to user1234 | PermalinkReply |
|
Tejas
Posted in reply to user1234
| On Saturday, 31 July 2021 at 13:34:25 UTC, user1234 wrote:
> On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:
> class A{
~this(){}
destructA(){
~this()
}
}
class B:A{
~this(){}
destructB(){
~this();
~super();
}
}
This could allow @nogc crowd to run destructors without calling destroy .
Yes, derived to base conversion is still a thing and someone who invokes the destructor just by looking at the parameter's type could get fooled, atleast we will have a way to destroy class instances without the gc.
Are there other problems? I'm genuinely curious.
I guess we can still just define normal methods and invoke them, but atleast this will allow us to maintain consistency with the gc crowd.
destroy is not the problem, see
https://forum.dlang.org/post/jsrjgmeblfukwhqbwjab@forum.dlang.org
the problem is what is called in destroy()
see https://forum.dlang.org/post/rdqqqqcadsqsmszqgslr@forum.dlang.org
for a very simple solution.
It is simple indeed, but not very simple.
If what I'm asking for is not too hard to implement and makes it, we can still use new , destroy will be unnecessary since we can use an explicit method(just like your solution) , or we won't even use that if we're willing to let RAII do the work(I'm talking of allocating to a scope qualified variable, or rt.alloca or std.typecons.scoped ).
If we do this, the gc crowd will not be completely alienated when reading our code, since it's not out of the ordinary(assuming we use RAII; using the destruct methods explicitly... well that's atleast better than seeing both construction and destruction done in a weird way)
|