D's Destructors are What Scott Meyers Warned Us About

[sarn]

On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
> How is __vdtor is going to be called, via destroy or via 
> directly?

Code using destroy() can still use destroy().  Otherwise, __vdtor 
would be callable in the same way that __dtor and __xdtor are.

The plan is to have a better, safer, less problematic (with 
attributes) solution to what __dtor and __xdtor do with classes, 
so that longer term we can deprecate and remove the old way.

> The issue that I see that your going to create a "BaseObject" 
> for every attribute or combination of said attributes. Which 
> creates way too much code bloat. Even more so with the 
> possibility of adding more attributes in the future.

So, I won't say the problem doesn't exist, but it's nowhere near 
as bad as that.

The idea isn't to have a BaseObject for every possible 
combination of attributes.  The BaseObject UDA is just a solution 
to the problem destructors have with inheritance+attributes.  
Once you have a base class marked BaseObject, you can derive from 
it and add whatever combination of attributes you like.

The BaseObject-marked class can have as much functionality as 
needed, except it can't have a non-trivial destructor.  That's 
okay for the immediate problems of implementing ProtoObject and 
__vdtor, and making safe containers, and improving C++ interop 
and -betterC code.  If needed in future, destructor support could 
be added in the existing language by exploiting attribute 
inference, but maybe by that time it would be better to make 
language changes and turn BaseObject into a no-op.  It doesn't 
matter.  I just think it's better to have a viable migration plan 
that doesn't start with "let's make all these language changes 
first".