DMD 0.177 release
Andrei Alexandrescu (See Website For Email)
SeeWebsiteForEmail at erdani.org
Mon Dec 11 11:52:23 PST 2006
Sean Kelly wrote:
> Brad Roberts wrote:
>
>>
>> Since the desired behavior is construction, let's stop kidding
>> ourselves and actually give structs both the behavior and the syntax
>> of construction, please? And while you're in there.. how about
>> destruction and RAII?
>
>
> What ever happened to structs as aggregates? I thought this was their
> entire purpose for being in D. Adding ctors makes sense because it
> merely simplifies initialization, but adding dtors, copy semantics, and
> opAssign all seem bent on making structs into something they're not.
> After all, isn't that why we have classes? In fact, many of the
> instances where I was inclined to use structs simply to avoid the GC
> evaporated when stack construction of classes was added a few releases
> ago. Aside from the addition of a ctor, I'm quite happy to leave
> structs exactly as they were before 177. That said, I suppose I can
> appreciate the desire to give classes opAssign (even though it's
> somewhat weird), and perhaps the operator was added to structs simply
> for the sake of consistency.
Classes are different from structs in two essential ways:
1. Polymorphism
2. Referential semantics
The two are actually interdependent, as you can't have polymorphism
comfortably unless you have reference semantics.
That's the important distinction. Other than that, it's good that they
share a number of valuable properties. Take private state for example.
structs as sheer unchecked aggregates would provide too little value to
be useful. Most of the time, aggregating some state together (date,
time, etc.) comes together with some desirable invariant that the
aggregate should hold, meaning that not all possible bit patterns of the
aggregate can be meaningful. So it's useful that struct has private
state. Consequently, they should have member functions (setters,
getters) and the such. They also should have constructors so they can
put themselves in a meaningful initial state, and should have opAssign
so they allow controlled overwriting of their state. (It's an accident
that opAssign from the same type has not been implemented yet; it can be
safely allowed.)
On the other hand, intercepting _duplication_ of structs naively would
be a major breach in the object model, because it would frontally
collide with (2) above: structs are values and the compiler can move and
copy structs around discretionary using bitwise copying. That's why D
currently does not allow interception of copy construction and
destruction. It might in the future, but in a way that does not clash
with the object model. (That is doable.)
So my point was, as attractive the simple mantra "structs should be
aggregates" is, it turns out it's not that useful. So it's great that D
supports efficient and safe user-defined values.
Andrei
More information about the Digitalmars-d-announce
mailing list