• ketmar (3/3) Jun 27 2015 is it safe to call `GC.removeRange` in dtor? i believe it should be safe...
• Steven Schveighoffer (7/10) Jun 30 2015 Hm... I can't see any reason why it wouldn't be allowed. removeRange
• rsw0x (4/7) Jun 30 2015 It's not documented. Afaik parts of the standard library depend
• ketmar (2/2) Jul 01 2015 thank you both. then i think that it should be explicitly stated

ketmar <ketmar ketmar.no-ip.org> writes:

is it safe to call `GC.removeRange` in dtor? i believe it should be safe,=20
so one can perform various cleanups, but documentation says nothing about=20
guarantees.=

Steven Schveighoffer <schveiguy yahoo.com> writes:

On 6/27/15 5:53 PM, ketmar wrote:
 is it safe to call `GC.removeRange` in dtor? i believe it should be safe,
 so one can perform various cleanups, but documentation says nothing about
 guarantees.

Hm... I can't see any reason why it wouldn't be allowed. removeRange 
shouldn't allocate, so the one forbidden thing is not used.

And removing a range, by definition, means it's not being collected. So 
you can be assured that the data still exists.

I'm not 100% sure, though.

-Steve

"rsw0x" <anonymous anonymous.com> writes:

On Saturday, 27 June 2015 at 21:53:33 UTC, ketmar wrote:
 is it safe to call `GC.removeRange` in dtor? i believe it 
 should be safe, so one can perform various cleanups, but 
 documentation says nothing about guarantees

It's not documented. Afaik parts of the standard library depend 
on this behavior so I'd say "ok*" where the asterisk means submit 
a specification update.

"ketmar" <ketmar ketmar.no-ip.org> writes:

thank you both. then i think that it should be explicitly stated 
in core.memory.