Deprecating this(this)

[ag0aep6g]

On 04/03/2018 08:57 PM, Andrei Alexandrescu wrote:
> Well... not really. This is because .init is really an inert state - 
> null indirections, no state allocated etc.

.init can have non-null indirections:

     struct S { int[] a = [1, 2, 3]; }
     static assert(S.init.a.ptr !is null); /* passes */

But maybe it shouldn't. It leads to problems with immutable, because the 
same .init with the same `a` is used for both mutable and immutable 
objects. https://issues.dlang.org/show_bug.cgi?id=10376

As far as I see, a const/immutable postblit working like a constructor 
wouldn't have that particular problem, because the copy is always made 
from another const/immutable object, so there wouldn't be aliasing with 
mutable data.

But there might of course be other problems with indirections, which I 
don't see right now. I'd love to see any examples, though. They probably 
reveal weaknesses in .init/constructors, too.

> Makes typechecking easy, and 
> calling constructor on top of .init is what happens already. In 
> contrast, the postblit situash is very different - the fields already 
> contain "interesting" data, allocated resources etc. Calling a 
> constructor on top of that is not defined.

Well, the idea would be to define it. But if postblit goes away for 
other reasons anyway (like the atomic copy thing, or another mechanism 
being simply superior), then there's no point in pursuing this, of course.