destroy(someStruct)

[Chris Cain via Digitalmars-d-learn]

On Saturday, 20 September 2014 at 22:46:10 UTC, John Colvin wrote:
> import core.stdc.stdio;
> struct S
> {
> 	~this()
> 	{
> 		printf("%x\n".ptr, &this);
> 	}
> }
> void main()
> {
> 	S* sp = new S;
> 	destroy(*sp);
>
> 	S s;
> 	destroy(s);
>
> 	auto sa = new S[2];
> 	foreach(ref s_; sa)
> 		destroy(s_);
> }
>
> output:
>
> 4002dff0
> bfa89a70
> 4002dfe0
> 4002dfe1
> bfa89a70
>
> Note the double destruction of s
>
> Its seems that calling destroy on a stack-allocated struct is a 
> no-no (unless you have a re-entrant destructor). The other two 
> examples seem OK though.
>
> Am I in dangerous territory? Will I see unexpected 
> double-destructions in some cases?

That's how structs work, so yes. Structs will always run their 
destructor at the end of their scope if stack allocated. Pointers 
to structs are currently working somewhat in an unexpected manner 
(that is, AFAIK, they don't destruct even when deallocated, but 
theoretically they could be set up to do so). Arrays to structs 
will probably never see proper destruction (there was a 
conversation about it somewhere here in the forums between myself 
and another poster and they convinced me that it's not really 
going to be possible since, as far as the GC is concerned, it can 
never know which structs have been constructed/used in a given 
section of memory, of which an array/slice is a subset of, and 
must be destructed. So at the very least, you may end up 
destructing a struct's init state if a greedy implementation is 
ever done).

I personally always make my destructors work on already 
destructed structs/init'd structs and that's my official 
recommendation on the matter. You can get away with a struct that 
cannot do so iff you can guarantee that it will never be manually 
destructed and it will only ever be stack allocated (which, in 
general, is probably not a safe assumption to make).