DMD 0.177 release

[Bill Baxter]

Walter Bright wrote:
> It's time to put the recurring efficiency argument to bed. Consider this 
> D code:

That is a relief to know.  What about heap construction?  I think 
currently with the opCall approach you have to do something like:
   auto x = new Struct;
   *x = Struct(args);
Does that copy get optimized away too?

There are other issues people are concerned about also.   Maybe it does 
only take two extra lines to define a static opCall vs a constructor, 
but that extra two lines is basically redundant noise and makes static 
opCall look hackish.  And given that most every struct is going to need 
a constructor, it is hackish noise that we're all going to have to (and 
already do) see a lot.

Also the name "static opCall" doesn't exactly scream out "i'm a 
constructor". And there's no guarantee that if I'm given a random struct 
I'll be able to use StructName() as a constructor.  Users are free to do 
whatever they want with static opCall.  With a constructor you have to 
construct.  Just like you said "constructors should construct objects" 
-- ok, but static opCall is not intrinsically a constructor, any more 
than a function called make() is a constructor.  It might be used as a 
constructor, or it might not.

There's also the consistency issue, that if construction is done with 
'this()' for classes it should be done with 'this()' for structs.

I can kind of see why you don't want to use this() because in classes 
that's triggered by using the 'new' keyword, and for stack construct 
structs it makes sense to not use 'new'.  But then if structs can be 
value constructed with  x = Struct(), then why not classes too?  But 
classes have to be value constructed using 'scope'.

Ok, what if you just sidestep all that and introduce something like 
opCreate for structs.  Basically this would be identical to the current 
"static opCall", but you could write the code for it just like a 
constructor.  Like so:

    opCreate(int arg) {
       m_member = arg;
    }

I.e. you don't specify return type, return value, or 'static' etc.  It 
works just like a constructor, but you call it like static opCall.

    auto x = MyStruct()

It would be an error to have both a static opCall and an opCreate.

Of course at that point it really raises the question "why not just call 
it 'this' instead of opCreate".  And declare that for structs you can 
invoke 'this' by using x = MyStruct().

Anyway, I really don't see why it has to be an either/or situation.  Let 
people use this/opCreate for new code, and let them continue to use 
static opCall in old code.  But make it an error to have both in a 
struct.  What's so hard about that?

--bb