Dynamic array leak?

[Dgame via Digitalmars-d]

On Saturday, 12 August 2017 at 17:25:36 UTC, bitwise wrote:
> On Saturday, 12 August 2017 at 08:16:56 UTC, Temtaime wrote:
>>
>> Collect - is a hint to the GC, not an order. It can ignore 
>> this request.
>
> If this is the case, then D's GC should have an option to force 
> collection like C#'s GC:
> https://msdn.microsoft.com/en-us/library/bb495757(v=vs.110).aspx
>
>> Also do not rely on the gc calling a dtor - it is not safe and 
>> can be called totally randomed, so use RC instead or expicit 
>> destroy()
>
> RC is not applicable. I'm doing unit tests for a non-GC 
> container and trying to make sure all destructors are called 
> properly.
>
> Example:
>
> unittest {
>     auto a = List!int([S(0), S(1), S(2)]);
>     a.popBack();
>     assert(equal(a[], [S(0), S(1)]));
> }
>
> // lots of similar unittests
>
> unittest {
>     import std.stdio;
>     GC.collect();
>     assert(S.count == 0);
> }
>
> So if all goes well, S.count should be zero, but the arrays I'm 
> testing against are being allocated on the heap. Given the 
> conditions of the tests, it seems like GC.collect should be 
> able to reclaim those arrays after the unit tests have exited, 
> and in most cases does.
>
> The ideal solution though, would be to allocate those arrays on 
> the stack and avoid the problem altogether. There doesn't seem 
> to be any reasonable way to do it though.
>
> // won't this allocate anyways?
> S[2] b = [S(0), S(1)];
> assert(equal(a[], b[]));
>
> // why can't I just declare a static array inline?
> assert(equal(a[], int[2]{ S(0), S(1) }));

auto s(T, size_t n)(T[n] values)
{
	return values;
}

assert(equal(a[], [S(0), S(1)].s));