DMD 0.177 release

[Leopold Walkling]

Sean Kelly schrieb:
> 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

Why are opAssign overloads possible for structs? They lead to a bad 
style like the example above: It's possible to assign a primitive type 
to an aggregate type, without showing what is done in the code.