Deprecating this(this)

[Andrei Alexandrescu]

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