Deprecating this(this)

[ag0aep6g]

On 04/03/2018 05:13 PM, Steven Schveighoffer wrote:
> Unfortunately, I found out that it's not just "pre-filled with some 
> values". Member postblits are run before the containing postblit.
> 
> https://run.dlang.io/is/mt6eGa
> 
> So this means, the data that is available to the postblit has already 
> been processed.

There's a similar situation with constructors: A constructor can call 
another constructor, which can lead to double initialization of fields.

Example:

----
class C
{
     int x;
     this() immutable
     {
         this(42); /* Initializes x. */
         x = 13; /* Breaking immutable, or ok? */
     }
     this(int x) immutable
     {
         this.x = x;
     }
}
----

If there's a problem with running two postblits on the same field, then 
I think constructors probably have similar issue. I'm having a hard time 
finding a good example, though. One where we could break immutable in an 
obvious way or some such.

> It would only make sense to allow const postblits to have the same 
> constructor mechanism if the members all had no postblits.

Less drastically, we could also disallow writing to those fields that 
have their own postblit.

The analog with constructors would be disallowing writing to fields that 
have already been initialized by an implicit `super` call. Actually, 
that seems to be how it works, kinda-sorta:

----
class C
{
     int x;
}

class D : C
{
     int y;
     this() immutable
     {
         y = 1; /* accepted */
         x = 2; /* Error: cannot modify this.x in immutable function */
     }
}
----

Obviously, DMD doesn't check what C's constructor actually does (because 
it generally can't check that). It just considers initializing x to be 
C's responsibility.