Deprecating this(this)

[ag0aep6g]

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu 
wrote:
> 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.

Yeah, I absolutely see value in starting fresh with different 
syntax, even if you were just implementing the same postblit idea 
again.

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

I'd think that just letting the const/immutable postblit function 
see head-mutable fields would work.

But maybe that's way harder to implement than writing it down the 
forum. If that's so, then fair enough. I know that I won't be 
able to implement it.

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

Interesting. I've got no armchair expertise on this one.

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

I think I don't understand this one. Could you give an example in 
code?

Are you saying that we'd need to define all these:

     this(this)
     this(this) const
     this(this) immutable

even if they do the same thing? Wouldn't `this(this) inout` take 
care of this?