DMD 0.177 release

[Burton Radons]

Walter Bright wrote:
> 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.

Do you have a single instance of a static opCall being used for 
construction where you don't just create a variable on the stack, build 
it, and return it? Because that's all I've ever done. Hundreds of times. 
Nothing else, and it just ends up being useless fluff making code harder 
to read than it should be.

The opposite end of this would be so easy - if classes didn't have 
constructors. They don't actually need them after all - you just need to 
have the ability to create a blank instance. But can you see how much of 
a pointless pain in the ass that would be? That's exactly how it is in 
structs right now.

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

Yeah, I've never liked C++'s handling of this, it looks way too much 
like a function call.