Deprecating this(this)

[ag0aep6g]

On Tuesday, 3 April 2018 at 12:52:00 UTC, Andrei Alexandrescu 
wrote:
> 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.

So constructors, including const/immutable ones, basically work 
the same as postblit already? You get an object pre-filled with 
some values, and then you can "initialize" the fields some more 
if you want.

[...]
> What if the user code reads the value?
>
> * Often people use this(this) to bump a reference count a la 
> "if (pcnt) ++*pcnt;"

Because of the indirection, that can only be done in a mutable 
`this(this)`. Otherwise you violate the const/immutable guarantee 
of the original object.

> * People may pass the field by reference to an opaque function. 
> What type does the field have?

Fully const. Same as in a constructor.

[...]
> 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.

A const constructor currently accepts both of those. So the 
second one can apparently be considered "initialization" as well? 
Or should a const constructor not be allowed to do that?