Steven Schveighoffer Wrote: > On Tue, 10 Aug 2010 16:33:08 -0400, foo <[email protected]> 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
Let me add to the above, that the GC should NOT manage structs allocated on the heap. structs should only provide deterministic semantics.
