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?
