On 04/03/2018 07:36 AM, ag0aep6g wrote:
For constructors, we say that the first assignment is actually
initialization. The compiler might or might not put the .init value down
before calling the constructor. Doesn't matter, because the constructor
will overwrite it anyway, and nothing of value is lost.
What happens in fact is you are guaranteed the .init value is there.
Much later, well after semantic checking, the backend optimizer removes
dead assignments on primitive data.
We can do the same with the postblit function: First assignment is
actually initialization. When the compiler sees that the postblit
function initializes a field, it can skip that field when blitting.
What if the user code reads the value?
* Often people use this(this) to bump a reference count a la "if (pcnt)
++*pcnt;"
* People may pass the field by reference to an opaque function. What
type does the field have?
But
it can also just blit the whole struct, because it doesn't matter if the
value just gets overwritten.
In other words, a postblit function can either:
1) use the blitted value as a starting point, like a constructor can use
the .init value, or it can
2) initialize the field itself.
Would make perfect sense to me.
In case (1) things can get quite confusing. Inside a postblit,
field = TypeOfField(100);
is a call to the constructor, whereas
field = TypeOfField(field.x + 100);
is a call to the assignment operator.
Andrei
