DMD 0.177 release

[Bruno Medeiros]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.)
> 

"allow controlled overwriting of their state" -> Would that be for the 
case where the struct's private state (aka abstract state) is not just 
the bit pattern value of the struct, but also the contents of 
pointer/reference members?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D