DMD 0.177 release

[Sean Kelly]

Stewart Gordon wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> Walter Bright wrote:
>>>> I don't think that'll work. He'll wind up being forced to set all 
>>>> the fields.
>>> Doesn't follow - there might not be any to set other than those that are
>>> an inherent part of the assignment operation.
>>
>> But if there *are* other fields that shouldn't be set, a rule to 
>> preclude those cases would be a problem.
> 
> Exactly.  *If* there are other fields that shouldn't be set.  Do you 
> even understand a word of what Chris is proposing?
> 
> The programmer would have a choice - opAssign returning void to modify 
> in-place the object referenced by the lvalue, or returning a new object 
> that will be assigned to the lvalue.  What is this precluding?

Just a few thoughts.  If this change is implemented, it should apply to 
all assign ops, not just opAssign itself.  So opAddAssign, opMulAssign, 
etc.  Also, it seems like this could give rise to some interesting behavior:

     class MyClass
     {
         int val;

         this( int x )
         {
             val = x;
         }

         MyClass opAssign( int x )
         {
             return new MyClass( x );
         }
     }

     void fn( MyClass c )
     {
         c = 42;
     }

     MyClass c = new MyClass( 0 );
     fn( c );
     writefln( c.val );

Based on this suggestion, the above will print '0', not '42'.  This is 
actually kind of an interesting situation, as it offers the possibility 
of making non-inout reference parameters immutable with respect to 
assign operations.  The other consequence being that assign operations 
could change the address of a class reference as a side-effect, which 
may have an impact on optimization.  It also may interact somewhat oddly 
with associative arrays and such, depending on how the compiler 
generates code.  ie.

     MyClass[int] aa;
     aa[0] = new MyClass( 0 );
     aa[0] = 42;
     writefln( aa[0].val );

What will the above print?  This sort of behavior would need to be 
defined in the spec.


Sean