Thread overview
Why are class methods not allowed to call cons/destructors?
Jul 31, 2021
Tejas
Jul 31, 2021
user1234
Jul 31, 2021
Tejas
Jul 31, 2021
Tejas
Jul 31, 2021
kinke
Jul 31, 2021
Tejas
Jul 31, 2021
kinke
July 31, 2021
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.

July 31, 2021

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.

July 31, 2021

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)

July 31, 2021

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.

Both solutions also suffer from cast, so one is not better than another(except that your solution doesn't require a language change, which makes it more feasible to use).

I'm simply curious why the requested behaviour is not available in the first place.

July 31, 2021

This is possible via:

__dtor();
super.__dtor();
July 31, 2021

On Saturday, 31 July 2021 at 13:57:40 UTC, kinke wrote:

>

This is possible via:

__dtor();
super.__dtor();

WHOO YEAH!!!
THANK YOU SO MUCH :D

July 31, 2021

On Saturday, 31 July 2021 at 13:59:46 UTC, Tejas wrote:

>

On Saturday, 31 July 2021 at 13:57:40 UTC, kinke wrote:

>

This is possible via:

__dtor();
super.__dtor();

WHOO YEAH!!!
THANK YOU SO MUCH :D

Heh you're welcome. Note that you'll probably want __xdtor(), which also destructs fields with dtor (no base fields - super.__xdtor() for the immediate base class etc.).