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.
