Why are class methods not allowed to call cons/destructors?

[Tejas]

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)