DMD 0.177 release

[Sean Kelly]

John Reimer wrote:
> 
>  From the perspective of setting initial state, classes in the OOP 
> context use constructors to do that.  Structs were never intended to 
> have OOP like syntax (or so it seems to me).  Why can't structs just use 
> an initializer like constants or statics?  I notice that Walter has 
> added the struct initialization using S(x) syntax.  I think it is 
> somewhat strange, but I suppose that was designed to be an alternative 
> to constructor initialization?   What happened to something like a 
> struct literal intializer (which only works for static structs and 
> constant values)?  Why can't such initialization be extended to local 
> structs?
> 
> ....
> struct S
> {
>    int i;
>    bool b;
> }
> 
> static S t = { 5, true };  // must be "static" or initialization won't work

I think the problem here is that such initializers would not apply to 
private data, and more to the point, a ctor can do more than simply 
assign a constant to each member of the struct.  But it would be nice if 
this syntax worked for non-static structs anyway.

> But I guess as soon as we start adding "methods" to the struct that are 
> responsible for changing state in the struct, a whole new set of 
> principles comes to work.  Adding constructor funtionality via "this()" 
> is only one way to fix it.  opCall, the current way, is a rather ugly 
> default.  If it is important to keep structs distinct from classes, then 
> structs need to adopt a alternate way of doing initialization (but 
> please not opCall).  I don't think "this()" really is the optimal way, 
> though perhaps the most familiar due to the influence of classes.  I 
> think there should remain a strong distinction between class and struct.

As do I.  And I suppose the presence or lack of polymorphism is a 
sufficient distinction--the underpinnings for polymorphism do have a 
fairly significant impact on how an object is represented internally, etc.

> If, nevertheless, Walter decides to implement a "this" constructor for 
> struct, I really hope he doesn't feel the need to go with a destructor 
> and more class-like functionality as well.

The idea of a dtor for structs doesn't make much sense to me because of 
the bit-copy semantics.  When would the dtor for a struct used as a 
return value be called?


Sean