On 4/3/18 4:26 PM, ag0aep6g wrote:
On 04/03/2018 05:13 PM, Steven Schveighoffer wrote:
Unfortunately, I found out that it's not just "pre-filled with some values". Member postblits are run before the containing postblit.

https://run.dlang.io/is/mt6eGa

So this means, the data that is available to the postblit has already been processed.

There's a similar situation with constructors: A constructor can call another constructor, which can lead to double initialization of fields.

Example:

----
class C
{
     int x;
     this() immutable
     {
         this(42); /* Initializes x. */
         x = 13; /* Breaking immutable, or ok? */

IMO, breaking immutable.

     }
     this(int x) immutable
     {
         this.x = x;
     }
}
----

If there's a problem with running two postblits on the same field, then I think constructors probably have similar issue. I'm having a hard time finding a good example, though. One where we could break immutable in an obvious way or some such.

You may NOT want to run a postblit on the member. If all you are going to do, for example, is reassign a variable, then running the postblit, and then the destructor, just so you can overwrite it is pointless.

But more importantly, if the postblit of the member does something crazy like stores a reference to itself as an immutable elsewhere, and then the compiler allows overwriting, we now have problems.

I think the better mechanism for immutable copying would be to have a copy constructor that starts off with T.init, and is passed the object to copy from. That seems to be a direction Andrei is considering.

-Steve

Reply via email to