Deprecating this(this)

[Jonathan M Davis]

On Sunday, April 01, 2018 14:55:07 ag0aep6g via Digitalmars-d 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.

One issue is that postblit constructors fundamentally don't work with const.
The problem is that a postblit constructor works by copying the object and
_then_ mutating it, and you can't mutate a const object. To cleanly deal
with const, you need something more like a copy constructor where you
initialize it with the adjusted values directly rather than mutating the
copy.

> 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.

Avoiding any breakage would be ideal, but it's unlikely that that can be
done if we want to make copying const objects work properly - not unless we
did something like use postblit constructors for mutable objects and copy
constructors for const objects, and that would just cause other problems
(including having to duplicate the code that deals with copying an object if
it's going to work with const). On the bright side, if we're replacing
postblit constructors with some other type of constructor for copying, it
should be a pretty straightforward process. But there isn't much point in
worrying about how much breakage there's going to be before we really know
where we want to go with this. At this point, it's just clear that as things
stand, postblit constructors have some definite problems (some which are
implementation issues and some which are language design issues), and based
on past discussions on this and previous attempts to fix some of the
problems with postblit constructors, it seems pretty unlikely that we can
fully fix postblit constructors. I'm sure that we could fix some of the
issues, but others (most notably, the issues with const) seem pretty
intractable.

- Jonathan M Davis