Deprecating this(this)

[Andrei Alexandrescu]

On 4/1/18 10:59 AM, Nicholas Wilson wrote:
> On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu wrote:
>> There's a mix of fundamental flaws and bugs. I'll get to the flaws in 
>> a second. About the bugs: people have altered their code in various 
>> ways to work with the bizarre semantics of this(this). Now, if we fix 
>> various bugs in this(this) by virtually redefining it, then we'll 
>> break a lot of code in a lot of ways. To wit, we fixed a small issue 
>> and it already created problems: 
>> https://github.com/dlang/dmd/pull/8032. That didn't contribute to the 
>> decision but is quite illustrative.
>>
>> I found two fundamental flaws with this(this):
>>
>> 1. For immutable objects, typechecking in the presence of successive 
>> modifications of data (first assignment by the compiler, then 
>> modification by the user) is very difficult if not impossible. I don't 
>> know how to do it. The single initialization model (raw/cooked) used 
>> currently in regular immutable constructors works reasonably well and 
>> is robust.
>>
>> 2. For shared objects, the part done by the compiler and the part done 
>> by this(this) should be synchronized together. This makes it 
>> impossible for the user to e.g. define a struct that gets copied 
>> atomically.
>>
> 
> See my other reply: but why is it necessary to consider the blit 
> logically distinct from the postblit w.r.t to program flow observability?
> 
> for 1. consider
> immutable foo = ...;
> immutable bar = foo;
> to be
> immutable foo = ...;
> immutable bar = () {mutable _ = bitcopy(foo); _.__postblit(); return _;}();

Negative. The problem is typechecking postblit itself, not its invocation.

> for 2. you would have to synchronize anyway for shared, it makes no 
> difference.

Negative. Consider:

shared struct Point
{
     private long x, y, z;
     private Mutex mutex;
     ...
}

Task: define the copy primitive of Point so atomically copy x, y, and z 
using mutex. The problem is, the compiler will memcpy the three longs 
non-atomically before the user even gets a crack at intercepting the 
operation.

>> There'd be an additional issue - this(this) is non-templated, which 
>> requires combinatorial additions when qualifiers are present on the 
>> source or destination side.
> 
> (Perhaps this is what you're referring to, but all you have said so far 
> is "this doesn't work and we need to fix it") the post blit is surely 
> like a destructor: there's only one way to do it, irrespective of the 
> attributes, especially of the intermediate is considered mutable until 
> the end of post blit, like static module constructors initialising 
> global immutables.

Negative. Ignoring qualifiers during copying opens holes in the type 
system the size of China. Or at least Australia as it were :o). Consider:

int[] sneaky;
struct A
{
     private int[] innocent;
     this(this)
     {
         sneaky = innocent;
     }
}
void main()
{
     immutable a = A([1, 2, 3]);
     auto b = a;
     sneaky[1] = 42; // oops
     import std.stdio;
     writeln(a.innocent); // ooooops
}

Sadly this (and many similar ones) compiles and runs warning-free on 
today's compiler. We really need to close this loop, like, five years ago.

> I agree that we should fix any type checking bugs that may be present, 
> and that we should strive to not make the same mistake twice, however I 
> wouldn't call either of the above cases a showstopper. You will need to 
> show more of what is broken and why it is broken given the expected 
> breakage.

Such discussions will be indeed present in the DIP.


Andrei