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

[John Burton]

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.

The explanations there make some sense to me.

Is this actually working as intended? (Just not how you'd hope it 
works)?