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)
