On Tue, 10 Aug 2010 16:33:08 -0400, foo <f...@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
