DMD 0.177 release

[Sean Kelly]

Chris Nicholson-Sauls wrote:
> Burton Radons wrote:
>> - Casting a value v to a struct S is now rewritten as S(v).
>>
>> I'm 100% against this. This is what C++ does, and it conflates 
>> construction and casting; with some VERY simple examples (such as the 
>> first one we think of when we think of additional types, bignums), 
>> there's an ambiguous conflict because one of the constructors should 
>> have a count of how many digits you want - and one of the casters 
>> takes an integer for a value to initialise to. My solution at the time 
>> was to add a dummy argument to the constructor so that the compiler 
>> didn't try to match them, which is absurd.
>>
>> I don't know why C++ was designed like this when its error was so 
>> blatant, but D doesn't need to replicate its mistake. "S.opCastFrom 
>> (v)" please, except that it shouldn't be static either.
> 
> Essentially agreed.  I'm not entirely fond of the "silent" new opAssign 
> either, because of the visual ambiguity it can lead to.  (Its worth 
> noting that, even though '='->opAssign is listed in the spec, the bottom 
> of the same page still lists '=' among the operators which will not be 
> given overloads.  Hm.)

Same.  And frankly, I'm having trouble coming up with a practical use 
for the new opAssign.  For one thing, it isn't commutative:

     auto c = new MyClass;
     int  i = 5;
     c = i; // will work
     i = c; // won't work

And now structs have an opAssign but still have binary copy semantics 
and no ctor/dtor support.  The result is totally confusing.  What was 
the use case for this feature?


Sean