DMD 0.177 release

[Sean Kelly]

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

Certainly.

> 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.)

Point made.  And I suppose opAssign isn't truly linked to the idea of 
object copy semantics--I've just gotten used to associating the two 
because of my experience with C++.

> 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.

structs as aggregates do come in quite handy for a few specific 
situations, but I agree that they aren't tremendously useful in the 
general sense.  It's beginning to seem, then, that common value types in 
D will be represented as structs, with classes reserved for those types 
with copy requirements.  Once implicit cast support is added, it seems 
we'll be in pretty good shape for UDTs in D.  And here I'd come to 
accept that we'd never have them :-)


Sean