Temporary objects as function parameters or when-is-this-shit-going-to-end?

[Steven Schveighoffer]

On 10/17/17 12:27 PM, John Burton wrote:
> On Friday, 13 October 2017 at 10:35:56 UTC, Jack Applegame wrote:
>> If you don't want to get the great PITA, never create temporary 
>> objects in function parameters.
>> I recently spent a whole day digging through my reference counted 
>> containers library. But nasty bug was not there, but in the compiler.
>>
>> Look at this: https://glot.io/snippets/eui2l8ov0r
>>
>> Result:
>>> Bar.this(int): 7FFD3D60CD38
>>> fun: 7FFD3D60CD20
>>> Bar.~this(): 7FFD3D60CD20
>>
>> Compiler creates struct on the stack and silently (without 
>> postblitting and destruction old object) moves it to another address. 
>> Is it normal? I don't think so.
>>
>> But that's not the most fun.
>>
>> Look at this: https://glot.io/snippets/eui2pjrwvi
>>
>> Result:
>>> Bar.this(int): 7FFF87DD2D31
>>> fun: 7FFF87DD2CE0
>>> Bar.~this(): 7FFF87DD2CE0
>>> Bar.~this(): 7FFF87DD2D31
>>
>> WAT??? Compiler creates struct on the stack copies it without 
>> postblitting and destructs both objects.
>>
>> But if you create the structure before calling the function, then all 
>> will be well:
>> https://glot.io/snippets/eui2vn2bu1
>>
>> All this greatly angered me because there are several issues related 
>> wrong struct construction and destruction in the bugtracker. Because 
>> of these bugs my low level libraries full of strange hacks.
>>
>> I want to ask. How you guys are going to create a reliable RC library, 
>> if such fundamental bugs hang in the issue tracker for months and 
>> years. And instead of fixing them, you develop new minor bells and 
>> whistles.
>>
>> See: https://issues.dlang.org/buglist.cgi?quicksearch=destructor
>>
>> Since I myself can't fix such bugs (my knowledge in this area are 
>> extremely small), I have a question to Andrei Alexandrescu:
>> Can I donate to the D Foundation and that my donations would be aimed 
>> at fixing exactly these bugs?
> 
> Is this a bug?
> Reading the chapter "7.1.3.5 They Whys of this(this)" in my D 
> Programming Language book it says that the compiler is free to elide the 
> call to this(this) when it can prove that the source of the copy will 
> not be used after the call.

It is allowed to, yes, and it should in this case.

> The explanations there make some sense to me.
> 
> Is this actually working as intended? (Just not how you'd hope it works)?

No, if a postblit is called, then an equivalent destructor should be 
called as well. The number of constructors + postblit calls should equal 
the number of destructor calls. Otherwise, you can't do things reliably 
like reference counting.

In this case, an extra destructor call is made without a corresponding 
postblit or constructor.

-Steve