struct and default constructor

[dcrepid via Digitalmars-d]

Okay, I'm still kind of new to this language, so forgive me if I 
see things a little differently than long time users..

Here's what I see though.

With Walter's description of what structures should be, it seems 
to me to be slightly at odds with what D structures are capable 
of, and in fact what they are being used for in a number of 
places ('fixing' GC, adding reference counting, providing RAII, 
etc).

Structs are classically POD types, as we know from C. But with D 
you've added overloaded constructors, destructors, member 
functions etc. To me that more or less defines an object, albeit 
one with special limits.  If you don't want to call them objects, 
thats fine. But the fact that they have customizable behavior in 
creation, copying, moving, and destruction means that they are 
much more than just a plain old data type with generic T.init 
states. They are a kind of living object, yea?

And it seems to me that the default constructor is just the last 
component left to cement the structure as an object. It seems 
curious that you would allow the ability to disable default 
construction and copy construction, and allow hiding of 
constructors, etc.. but then determine that default constructors 
are going too far?

Sure, having a guarantee that a struct will always be created 
without a fail state is a great concept.  But why then haven't 
they just been kept as a collection of data types, and another 
'scope object' been created instead?

It seems what has happened is a FrankenStruct monster was created 
in the midst of trying to find some midway point between D 
objects and 'scope objects'..

I would myself love to use objects all the time, but I see these 
problems that currently only the FrankenStructs resolve:

1. Objects are basically pointers, and can be null pointers at 
that! (To me, that's C-levels of safety there)
    However: Structs are always created.
2. Without assigning something to an object, there's obviously no 
real initialization.
    However: Structs are initialized on creation.
3. Object Destructors are called 'sometime in the future' when GC 
runs. Cleaning up resources is discouraged as those resources 
might have been cleaned up by the GC?
    However: Struct destructors run when they are out of scope.
4. Objects always have at least one level of indirection (and a 
lot of extra data)
    Structs are there where you define them. (with no extra data)

I may not be 100% on all of this, I'm still learning. But many 
times browsing the forums, reading the D books etc, I see the 
solutions to D object problems becoming this: wrap it with a 
struct.  So whether its something like RefCounted, Scoped, 
NonNullable, UniqueArray etc.. the problems with D objects are 
fixed by relying on the guarantees provided by structures to 
solve them.

I dunno, to me it all seems a bit discordant with what Walter 
seems to want them to be?

(Sorry in advance if any of this comes off as mean or provoking.. 
I'm just sharing how I view the language design)