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
