DMD 0.177 release

[Jarrett Billingsley]

"Walter Bright" <newshound at digitalmars.com> wrote in message 
news:elf9mn$snp$1 at digitaldaemon.com...

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

And are they _really_ equivalent?  Where's the 'this' pointer in a static 
opCall()?

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

>> 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);".

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

That makes sense.  It gives the utility of opAssign in most cases without 
the scary stuff.

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

:/

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