DMD 0.177 release

[John Reimer]

On Mon, 11 Dec 2006 10:50:41 -0800, Sean Kelly <sean at f4.ca> 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.
>
>
> Sean


I used to be convinced that struct's needed constructors; but now I see  
that there is a steam-roll effect as the demand for one class-like  
attribute is proposed: suddenly people want more class-related  
functionality or people argue that there is a basis for additional  
features for the sake of consistancy.  Then the redesign of structs starts  
taking on the appearance of a reegineered, specialized class -- something  
of a "context switch" too since classes use reference semantics.  Perhaps  
we should be careful about hurtling too far in the direction of C++?

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

The above only works for static Structs.  But that kind of initialization  
seems to be more consistant with the imperitive style of structs verses  
the OOP style of classes (if only non-statics could be initialized too,  
that is). When all is said and done, this is just like doing the same as  
S( 5, 2 ) since 0.177.

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.

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.

Ironically, I feel more sympathetic to what appears to be Walter's opinion  
on the matter this time around. :D

-JJR