Deprecating this(this)

[Andrei Alexandrescu]

On 04/02/2018 12:53 PM, Steven Schveighoffer wrote:
> On 4/2/18 11:57 AM, Andrei Alexandrescu wrote:
>> On 04/02/2018 10:59 AM, ag0aep6g wrote:
>>>
>>> That wouldn't be possible if `innocent` were only head-mutable in the 
>>> postblit function, instead of fully mutable as it is currently (bug).
>>>
>>> `innocent` would be typed as `immutable(int)[]`, and you could not 
>>> assign it to the fully mutable `sneaky`.
>>
>> Problem is we don't have head-mutable in the language.
> 
> This is the wrong way to look at it. Head mutable is a specialized 
> concept already implemented in constructors:
> 
> struct S
> {
>     int x;
>     int *ptr;
>     int *ptr2;
>     this(int xval, immutable int *ptrval, int *cantuse) immutable
>     {
>        x = xval; // ok, head mutable
>        //x = x + 1; // error, immutable field initialized multiple times
>        ptr = ptrval; // ok
>        // ptr2 = cantuse; // error, can't assign mutable to immutable
>     }
> }

I've asked Razvan to document how immutable constructors are exactly 
typechecked. My understanding is that they don't rely on some form of 
internal "head const" but instead on simple data flow - the first 
assignment counts as a constructor call. Consider the following example, 
which contains opaque methods instead of built-ins:

struct S
{
     int[] payload;
     S* another;
     this(int) immutable;
}

struct HasS
{
     S member;
     this(int  x) immutable
     {
         member = immutable S(1);
     }
}

This fails to link; the assignment is just a call to the (declared but 
undefined) constructor.

Such behavior is nice and easy to generalize to copy construction.

> We could have the same mechanism for postblit. Essentially, you should 
> be able to assign immutable fields once, but they shouldn't lose their 
> const protections (note the cantuse example).

Yes, with the distinction that is not "assign" but really "construction 
with assignment syntax".

> As was mentioned, because postblit on an immutable (or const) is ONLY 
> allowed for new data, there shouldn't be an issue.

The problem with postblit is there's "double construction", one done by 
the compiler, after which the user may want to assign something else. 
That's more difficult to typecheck than direct initialization.


Andrei