Deprecating this(this)

[H. S. Teoh]

On Sun, Apr 01, 2018 at 02:31:06PM +0000, Nicholas Wilson via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote:
> > 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.
> 
> I've always wondered about that, is the difference between that
> anything more than philosophical? Put another way if a this(this) is
> weakly pure, is there any safety issues with the compiler permitting
> the mutation on a (non-shared? not sure if this would be a
> requirement) const object? I'm not sure what the spec says, but if you
> take the view that the const object is no fully initialised until the
> postblit is done, then I don't see the problem.

Yeah I've been wondering about this too.  I mean, currently, ctors are
allowed to assign to immutable fields, because, well, it's
initialization, not after-the-fact mutation.  Why can't we extend this
to postblits?  Now, there's certainly the issue of ctors "leaking"
mutable references to immutable fields if not implemented properly, but
since postblits are run after a built-into-the-language copying of the
original, supposedly an opaque process, it seems reasonable enough to
allow the postblit to be regarded as initialization and able to assign
to const/immutable fields once.

At the very least, allow rebinding of const/immutable references in the
postblit. (Allowing straight-out reassignment may have adverse effects
if the copy shares a reference to an immutable object.)


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.