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