<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 14 Aug 2024 at 21:56, Dennis via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, 14 August 2024 at 09:19:55 UTC, Manu wrote:<br>
> Also surprisingly, if I comment out the constructor, the <br>
> compile error<br>
> about the destructor goes away. I can't see why the <br>
> constructor's existence<br>
> affects the destruction semantics in fun()?<br>
<br>
The compiler's logic goes as follows:<br>
<br>
```D<br>
return Thing(null);<br>
```<br>
<br>
Since `Thing` has a constructor, this gets rewritten to:<br>
<br>
```D<br>
return Thing().this(null);<br>
```<br>
<br>
Now we have a 'DotVarExp' with a struct literal on the left, and <br>
the struct has a destructor. Since internally expression <br>
temporaries can't have destructors, it gets extracted into a <br>
temporary variable:<br>
<br>
```D<br>
return ((Thing __slThing3 = Thing();) , __slThing3).this(null);<br>
```<br>
<br>
Then `__slThing3` goes out of scope and needs a destructor call.<br>
<br>
So clearly, in this case you don't want the temporary, but in <br>
other cases (`return Thing(null).field;`) you do need it, so I'm <br>
thinking about what the right conditions should be for the <br>
temporary.<br></blockquote><div><br></div><div>Well, the condition is that NRVO should elide the copy/move... it should be constructed at the caller's scope in this case.</div><div>Your example `Thing(null).field` is not the same thing, because it's not NRVO at all.</div><div><br></div><div>I guess this is a bug then?<br></div></div></div>