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