D's Destructors are What Scott Meyers Warned Us About

sarn sarn at theartofmachinery.com
Fri May 25 23:47:33 UTC 2018


On Thursday, 24 May 2018 at 12:26:00 UTC, Steven Schveighoffer 
wrote:
> I added the bug report here: 
> https://issues.dlang.org/show_bug.cgi?id=18903. I outline 
> exactly how to fix it, if anyone wants an easy PR opportunity.
>
> -Steve

Thanks for digging into that.

On Wednesday, 23 May 2018 at 23:18:46 UTC, Manu wrote:
> On 23 May 2018 at 15:47, sarn via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>> On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole 
>> wrote:
>>>
>>> I would consider the current state with classes a bug.
>>> So ticket please, it should not require a DIP to change 
>>> (although Walter
>>> may disagree).
>>
>>
>> Unfortunately, the way __dtor and __xdtor work for classes 
>> can't be changed without the risk of breaking code.  (Even if 
>> the current behaviour is broken, users might be working around 
>> it.)
>
> In what way is the current behaviour *broken*? (as opposed to 
> awkward, confusing, and poorly documented)

If c is a class instance, then c.__xdtor compiles and runs but 
can only be guaranteed to run the right destructors in special 
controlled cases where there's most likely a better way.

That std.signals code that Steven filed a bug report for is 
example of why we can't just fix the behaviour, though.  If we 
just fixed __dtor/__xdtor, any code that used std.signals would 
start having ugly bugs at run time.

I think that longer term we'll have to deprecate and remove these 
functions.


More information about the Digitalmars-d mailing list