DMD 0.177 release

[Walter Bright]

Jarrett Billingsley wrote:
> No offense, but would it honestly kill you to allow ctors in structs?  We've 
> been using static opCall as a _workaround_ for the lack of struct ctors, and 
> making it part of the language doesn't really seem to be addressing the 
> problem.  That, and it doesn't make any sense that classes use "this()" and 
> structs use "static S opCall()".  We're starting to get into "overloading 
> indexing in C++" territory.

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.

> That, and which would be more efficient?  The static opCall needs to return 
> an instance of the struct on the stack, which could be very inefficient for 
> large structs.  With a true ctor, the struct is passed by reference to the 
> ctor and has its fields set directly.

The optimizer removes the redundant copy, and builds the result directly 
into the target.

> And I also can't figure out how to make the implicit opCall work with more 
> than one parameter.  :P

S(1,2,3)

> I'm also a little wary about opAssign.  Not that I don't find it useful, 
> just that you've been vehemently opposed to overloading it in D for how many 
> years, and three weeks before 1.0 you reverse your opinion.  What does that 
> mean?

The problem I have, and still have, is the identity assignment. This is 
specifically disallowed with opAssign. I can go into the reasons why if 
you like.

Having opAssign for foreign types turns out to be needed for things 
like, say I want to build a ranged integer. This is an integer that can 
only have values between m and n. Without opAssign, I'd have to use a 
property:
	RangedInt!(m,n) r;
	r.value = 6;
It's just not right.

> But complaints aside, thanks for removing the []=>* implicit cast and the 
> bugfixes.  Man, this last month has been an exciting time for D :) 

For me as well!