Deprecating this(this)

[Nicholas Wilson]

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 _;}();

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

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

> 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

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.