On Monday, 28 May 2018 at 04:26:02 UTC, sarn wrote:
> On Sunday, 27 May 2018 at 22:27:52 UTC, sarn wrote:
>> I've been thinking this through a bit, and here's what I've got so far:
>
> Here's a tweak that should be implementable without any language changes:
>
> Instead of trying to detect an empty destructor, we use a UDA on the class --- call it BaseObject or something.  A BaseObject-marked class is meant to be something like Andre's ProtoObject, or a custom alternative base.  It must not define a destructor or include members with destructors (could relax this in future but works for now), and must only inherit from other BaseObject-marked classes.
>
> With that, __vdtor could be implemented using a template mixin.
>  For a BaseObject class, that would generate an empty virtual __vdtor.  For other classes, it would call __xdtor and then (non-virtually) call __vdtor for the superclass as long as it's not a BaseObject class.
>
> Can anyone see something I've missed?  I think it works with the current type system, makes Andre's ProtoObject possible while supporting subclassing with @nogc or whatever, and gives us safe class destructors that could be compatible with C++.
How is __vdtor is going to be called, via destroy or via directly? 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.

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

On Monday, 28 May 2018 at 22:37:01 UTC, sarn wrote:
> On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote:
>> [...]
>
> Code using destroy() can still use destroy().  Otherwise, __vdtor would be callable in the same way that __dtor and __xdtor are.
>
> [...]

Interesting... You don't mind me asking your assistance on writing DIP on this?  I have one set up already, and I needed help as
1.) This is my first time writing a DIP
2.) I don't know what main course of action to take regarding this issue.

On Monday, 28 May 2018 at 22:53:03 UTC, 12345swordy wrote:
> Interesting... You don't mind me asking your assistance on writing DIP on this?  I have one set up already, and I needed help as
> 1.) This is my first time writing a DIP
> 2.) I don't know what main course of action to take regarding this issue.

I want to write a draft of a DIP related to attribute inference next chance I get (possibly this weekend).  It's related to this, so I'll post the draft here.  You're very welcome to comment (or send PRs).

BTW, I'll just be following these guidelines and using accepted DIPs as examples:
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md
https://github.com/dlang/DIPs/tree/master/DIPs/accepted

On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote:
> (I'm referring to Scott's 2014 DConf talk: https://www.youtube.com/watch?v=KAWA1DuvCnQ)
>
> I was actually preparing a DIP about this when Manu posted to the forums about his own related problems with C++ interop.
>
> I traced a bug in some of my D code to my own misunderstanding of how D's destructors actually work.  So I did some research and discovered a bunch of edge cases with using __dtor, __xdtor and hasElaborateDestructor.  I tried reviewing the packages on code.dlang.org and some elsewhere (thankfully only about 1% of D packages use these functions directly) and it turns out I'm not the only one confused.  I don't have time to file bug reports for every package, so, if you're responsible for code that handles destructors manually, please do a review.  There's a *lot* of buggy code out there.
>
> I'm starting this thread to talk about ways to make things better, but first the bad news.  Let's use this idiomatic code as an example of typical bugs:

In the context of your blog post at https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html, I'm wondering if the changes in 2.081 help matters at all:  I'm wondering if any of the changes in 2.081 improves the situation here:  e.g. https://dlang.org/changelog/2.081.0.html#cpp_destroy

Mike

On Monday, 9 July 2018 at 01:19:28 UTC, Mike Franklin wrote:
> In the context of your blog post at https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html, I'm wondering if the changes in 2.081 help matters at all:  I'm wondering if any of the changes in 2.081 improves the situation here:  e.g. https://dlang.org/changelog/2.081.0.html#cpp_destroy
>
> Mike

I don't know yet, but, yeah, that work looks interesting and I definitely have to do some more testing.

BTW, I'm still interested in writing DIPs.  I've just been working a lot on another project lately.

On Monday, 9 July 2018 at 02:10:27 UTC, sarn wrote:
> On Monday, 9 July 2018 at 01:19:28 UTC, Mike Franklin wrote:
>> In the context of your blog post at https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html, I'm wondering if the changes in 2.081 help matters at all:  I'm wondering if any of the changes in 2.081 improves the situation here:  e.g. https://dlang.org/changelog/2.081.0.html#cpp_destroy
>>
>> Mike
>
> I don't know yet, but, yeah, that work looks interesting and I definitely have to do some more testing.
>
> BTW, I'm still interested in writing DIPs.  I've just been working a lot on another project lately.

I was thinking of rewriting my current DIP into introducing null function and recursive_destruct that can call on classes only if certain rules are checked.

-Alexander