Destructor semantics

[Steven Schveighoffer]

On Tue, 10 Aug 2010 16:33:08 -0400, foo <foo at bar.com> wrote:

> In light on recent discussions of clear() and the distructor it seems to  
> me that we are going backwards from one of D's great improvements over  
> C++ - the difference in semantics between structs and classes.
>
> IMO, instead of enhancing class desteructors they should be completely  
> removed and only allowed on structs with deterministic semantics and all  
> uses cases of class desteructors should be replaced with structs.
> Examples:
> class SocketConnection : Connection {
> // struct instance allocated inline
> SocketHandle handle;
> ...
> }
>
> OR:
>
> class SocketConnection : Connection {
> struct {
>    this()  { acquireHandle(); }
>   ~this() { releaseHandle(); }
> } handle;
> ...
> }
>
> The suggested semantics of the above code would be that creating a
> SocketConnection object would also construct a SocketHandle as part of  
> the object's memory and in turn that would call the struct's ctor.
> On destruction of the object, the struct member would be also destructed  
> and it's d-tor is called. This is safe since the struct is part of the  
> same memory as the object.
>
> in short, struct instances should be treated just like built-in types.
>

That doesn't help.  deterministic destruction is not a struct-vs-class  
problem, its a GC-vs-manual-memory problem.  A struct on the heap that is  
finalized by the GC has the same issues as a class destructor.  In fact,  
struct destructors are not currently called when they are heap-allocated  
because the GC has no idea what is stored in those memory locations.

-Steve