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
