Deprecating this(this)

[Steven Schveighoffer]

On 4/3/18 4:26 PM, ag0aep6g wrote:
> 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? */

IMO, breaking immutable.

>      }
>      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.

You may NOT want to run a postblit on the member. If all you are going 
to do, for example, is reassign a variable, then running the postblit, 
and then the destructor, just so you can overwrite it is pointless.

But more importantly, if the postblit of the member does something crazy 
like stores a reference to itself as an immutable elsewhere, and then 
the compiler allows overwriting, we now have problems.

I think the better mechanism for immutable copying would be to have a 
copy constructor that starts off with T.init, and is passed the object 
to copy from. That seems to be a direction Andrei is considering.

-Steve