Discussion Thread: DIP 1040--Copying, Moving, and Forwarding--Community Review Round 1

[Timon Gehr]

On 13.03.21 01:29, Max Haughton wrote:
> On Friday, 12 March 2021 at 23:52:00 UTC, Timon Gehr wrote:
>> On 11.03.21 23:39, Walter Bright wrote:
>>> On 3/11/2021 10:43 AM, Timon Gehr wrote:
>>>> [...]
>>>
>>> All the problems with const/immutable revolved around postblit. 
>>> That's why this proposal has zero reliance on postblit.
>>
>> My concern was that similar mistakes can be repeated. You don't ensure 
>> correctness just by avoiding the precise set of previous mistakes; 
>> it's always possible to make new, slightly different mistakes.
>>
>> The design of immutable and the design of postblit took place 
>> independently of each other and they ended up being incompatible. Why 
>> is the same thing not happening now? The DIP seems to assume there is 
>> no such thing as immutable, just like postblit did. A naive 
>> implementation of the DIP might therefore implicitly cast away 
>> immutable, just like postblit did.
> 
> Is the specific issue here a move from an immutable struct breaking the 
> immutable-contract silently?
> ...


Yes, one thing that could conceivably go wrong is this:

@safe:
int* global;

struct S{
     int* x;
     this(S other){
         global=other.x;
         this.x=other.x;
     }
     // ...
}

void main(){
     immutable s=S(new int);
     immutable t=s; // s moved, so move constructor is called
     assert(t.x is global.x);
}

This is similar to what went wrong with postblit.

> Thank you for raising it even if not because this needs to be hashed out 
> properly.

Exactly, the issue is basically, even if what happens is not memory 
corruption, maybe the DIP should state what it is that does happen. :)

E.g., I think it would be good to address questions like those somehow:

Is moving an immutable object allowed? (E.g., with @system variables I 
think you could have a @trusted immutable object that's backed by malloc 
and deallocated on destruction, can we move that?)


Is this a move constructor?

struct S{
     this(immutable(S) other)immutable{ ... }
}


On an unrelated note, I guess the DIP should also show how to actually 
declare a copy constructor. Is it this(ref S) ?