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.
