Odd Destructor Behavior

[Matt Elkins via Digitalmars-d-learn]

On Sunday, 7 February 2016 at 23:11:34 UTC, anonymous wrote:
> On 07.02.2016 23:49, Matt Elkins wrote:
>> Oi. Yes, I can, but it is quite a lot of code even if you 
>> don't count
>> that it is dependent on OpenGL, GLFW, and gl3n to run to this 
>> point.
>> This is why I was disappointed that simpler reproducing cases 
>> weren't
>> appearing. I should probably spend more time trying to reduce 
>> the case
>> some...
>
> Minimal test cases are great, but if you're not able to get it 
> down in size, or not willing to, then a larger test case is ok, 
> too. The problem is clear, and I'd expect reducing it to be 
> relatively straight-foward (but possibly time-consuming). Just 
> don't forget about it completely, that would be bad.
>
> Also be aware of DustMite, a tool for automatic reduction:
>
> https://github.com/CyberShadow/DustMite

Turns out it was less hard to reduce than I thought. Maybe it 
could be taken down some more, too, but this is reasonably small:

[code]
import std.stdio;

struct TextureHandle
{
     ~this() {}
}

TextureHandle create() {return TextureHandle();}

  struct TileView
  {
      @disable this();
      @disable this(this);
      this(TextureHandle a, TextureHandle b) {}
      ~this() {writeln("HERE2");}
  }

  struct View
  {
      this(int)
      {
          writeln("HERE1a");
          m_tileView = TileView(create(), create());
          writeln("HERE1b");
      }

      private TileView m_tileView;
}

unittest
{
     auto v = View(5);
}
[/code]

This yields the following:

[output]
HERE1a
HERE2
HERE1b
HERE2
[/output]

I would have expected only one "HERE2", the last one. Any of a 
number of changes cause it to behave in the expected way, 
including (but probably not limited to):
* Creating the TextureHandles directly rather than calling 
create()
* Using only one argument to TileView's constructor
* Removing TextureHandle's empty destructor

That last one especially seems to indicate a bug to me...