Deprecating this(this)

Kagamin spam at here.lot
Fri Apr 13 05:57:59 UTC 2018


On Wednesday, 4 April 2018 at 10:37:57 UTC, Steven Schveighoffer 
wrote:
> I would like to see more flexibility for copying.

It's a tradeoff between control and ergonomics.

>> import std.stdio;
>> 
>> immutable(int)* p;
>> 
>> struct S
>> {
>>      int x;
>>      this(this) immutable
>>      {
>>          x = 42; /* First write. */
>>          .p = &this.x;
>>          writeln(p, " ", *p); /* Prints some address and 42. */
>>      }
>> }
>> 
>> struct T
>> {
>>      S s;
>>      this(this) immutable
>>      {
>>          s = S(13); /* Second write. Breaking immutable? */
>
> Of course this doesn't compile, because s is considered 
> immutable by now. What I was saying is that we can't allow 
> postblit to modify data that has already been postblitted, 
> because of the reason this example is showing.

Assignment ends lifetime of the previous value, it will be just a 
dangling pointer.

AFAIK this is how reassignment works wrt destructors:

{
   immutable tmp=S(13);
   s.__dtor(); //if any
   s=tmp; //move into immutable storage
}

> I don't think you should be able to write to the same field 
> multiple times in an immutable/const constructor. If so, that's 
> a bug.

Stores to const fields are special, so it should be possible to 
track them in postblits too.


More information about the Digitalmars-d mailing list