Bug in RefCounted?

[Maxim Fomin]

On Tuesday, 29 October 2013 at 12:03:09 UTC, Rene Zwanenburg 
wrote:
> On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
>> The fact that structs are movable and there is too few struct 
>> runtime reflection makes them noncollectable. However, you can 
>> wrap struct inside class, in such case struct dtor will be 
>> called.
>
> Yeah, if wrapping inside a class wouldn't work either we'd be 
> in a whole new world of hurt.
>
> But what do you exactly mean by noncollectable? And what does 
> movability have to do with that? I think the memory will be 
> reclaimed without a problem, so new-ing a struct without 
> destructor would be fine. This doesn't leak:
>
> struct S
> {
> 	int i;
> }
>
> void main()
> {
> 	while(true)
> 	{
> 		new S;
> 	}
> }

I would say it leaks because dtor (if defined) is not called, 
although memory is reclaimed at some point. In my opinion struct 
movability is a problem for heap struct collection because it is 
hard to say judging to struct stack/heap pointer whether it 
should be collected or not. If you look at output from previous 
example,

ctor, 1
dtor, 7FFFF7ED8FF8, 1
ctor, 2
dtor, 7FFFFFFFDB30, 1

you will see that adressess are different and refer to stack, yet 
object is in the heap. By the way, there is another issue - if 
you have delegate inside struct method touching some field, than 
invoking such delegate after returning from method may break 
memory, because delegate references 'this' struct pointer, but it 
may be changed across lifetime. I am not sure whether some 
algorithm for solving heap struct collectibility can be made, but 
I don't have any idea right now.