• Tejas (25/25) Jul 31 2021 ```d
• user1234 (7/32) Jul 31 2021 `destroy` is not the problem, see
• Tejas (13/48) Jul 31 2021 It is simple indeed, but not _very_ simple.
• Tejas (6/41) Jul 31 2021 Both solutions also suffer from ```cast```, so one is not better
• kinke (5/5) Jul 31 2021 This is possible via:
• Tejas (3/8) Jul 31 2021 WHOO YEAH!!!
• kinke (4/12) Jul 31 2021 Heh you're welcome. Note that you'll probably want `__xdtor()`,

Tejas <notrealemail gmail.com> writes:

```d
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.

user1234 <user1234 12.fr> writes:

On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:
 ```d
 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.

Tejas <notrealemail gmail.com> writes:

On Saturday, 31 July 2021 at 13:34:25 UTC, user1234 wrote:
 On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:
 ```d
 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)

Tejas <notrealemail gmail.com> writes:

On Saturday, 31 July 2021 at 13:34:25 UTC, user1234 wrote:
 On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:
 ```d
 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.

kinke <noone nowhere.com> writes:

This is possible via:
```
__dtor();
super.__dtor();
```

Tejas <notrealemail gmail.com> writes:

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

kinke <noone nowhere.com> writes:

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.).