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