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.
