DMD 0.177 release

[Walter Bright]

Jarrett Billingsley wrote:
>> It turns out that static opCall() and this() are equivalent. C++ has some 
>> obscure rules to try to disambiguate them. I wished to avoid that problem, 
>> and since static opCall() is routinely in use, picked them.
> For classes they're not.  Why should structs be any different?  And even if 
> static opCalls are routinely in use, are they the best solution?

I've found they work well.

> And are they _really_ equivalent?

Not perfectly, but the differences are small.

> Where's the 'this' pointer in a static 
> opCall()?

It's in your return value.

>> The optimizer removes the redundant copy, and builds the result directly 
>> into the target.
> Wouldn't it be easier to just have ctors, so implementations don't have to 
> worry about writing an optimizer just to support this behavior?

You have to have the optimization anyway. My C++ compiler has had it 
since 1991 or so. It's oooold technology.

>>> And I also can't figure out how to make the implicit opCall work with 
>>> more than one parameter.  :P
>> S(1,2,3)
> 
> Oh.  I was thinking more along the lines of being able to do "S s(1, 2, 
> 3);".

I prefer:
	auto s = S(1,2,3);
to C++ style. static opCall fits right in.

> Though as was mentioned elsewhere, it's not commutative, so it's still not 
> possible to do
> 
> RangedInt!(m, n) r;
> r = 5;
> int x = r; // error

That's implicit casting from a struct. It'll probably wind up getting 
supported in one form or another.