Deprecating this(this)

[Andrei Alexandrescu]

On 4/1/18 8:55 AM, ag0aep6g wrote:
> On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:
>> On 3/31/18 8:32 PM, H. S. Teoh wrote:
> [...]
>>> What exactly is it about this(this) that blocks us from doing that?
>>
>> See the updated docs. Too many bugs in design and implementation.
>>
>>> Removing this(this) is going to be a huge breaking change far bigger
>>> than, say, removing autodecoding ever will be.
>>
>> We're not removing it as much as evolving it: we define an alternate 
>> copying mechanism, and once that is in tip-top shape, we deprecate 
>> this(this).
> 
> Is there a fundamental flaw in the postblit idea, or are you just going 
> to give postblit a new syntax, and try to avoid all the issues that 
> `this(this)` currently has?
> 
> If there's a fundamental flaw, I'd be interested in what it is. I can't 
> make it out in your additions to the spec, if it's in there. I can see 
> that `this(this)` is  a mess, but it also looks like a lot could be 
> fixed. For example, how it interacts with const/immutable is ridiculous, 
> but that could probably be fixed.
> 
> If you're just going for a clean slate, I can see the appeal. You avoid 
> dealing with the hard breakage that fixing `this(this)` would most 
> probably bring.

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.

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.

Please note that fixing one or two of these issues doesn't make 
this(this) viable - I'm mentioning various issues, each of which is a 
showstopper. Nevertheless knowing them is necessary so we don't make the 
same mistake again!


Andrei