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.
