On Wednesday, December 21, 2011 08:44:10 Jacob Carlborg wrote: > I thought that one of the problems with the GC and memory was that you > can't rely on when/if the destructors are called. With "dispose" it > would give the developer a reliable method to cleanup resources, > assuming "scope" or "delete" is used.
> I was thinking that classes could be the safe and default but and > scope/delete could be used as an optimization. Well, both delete and scope are going away, so std.typecons.scoped would have to be used instead, but that only really works for local variables. It would probably work for a member variable as well, but in both cases, you have to worry about the class going away when Scoped goes away and how that affects all of the references to it. If, on other hand, you use a ref-counted struct, it takes care of itself without the risks of the container going away while references to it still exist (unless you keep a pointer to it somewhere instead of the ref-counted struct). So, ref-counted structs would be much safer, and they could use advanced memory management internally by default, making them more efficient by default. What I really don't get, however, is how custom allocators would be of much use for classes unless the entire class is allocated that way (in which case, it's probably going to end up in a struct of some kind anyway unless you want the same issues that you get with scoped), since if the class is on the GC heap, its internal memory management couldn't release any of it until the container is collected by the GC. So, it seems to me that the desire for custom allocators would favor the use of ref-counted structs over classes. - Jonathan M Davis