On 4/2/18 1:08 PM, Andrei Alexandrescu wrote:
On 04/02/2018 12:53 PM, Steven Schveighoffer wrote:
As was mentioned, because postblit on an immutable (or const) is ONLY
allowed for new data, there shouldn't be an issue.
The problem with postblit is there's "double construction", one done by
the compiler, after which the user may want to assign something else.
That's more difficult to typecheck than direct initialization.
I was going to argue that it's not full construction -- it's just a copy
of bits. But I am incorrect.
My understanding was that postblit is called after the bits are copied,
but that isn't the case. Currently, the postblit of members is called
BEFORE the postblit of the container (or maybe as part of the postblit
of the container, but always at the start). This means that a member is
not a moved copy at that point, but a fully postblitted item. This also
means that it's not safe to assume head-const-ness.
This makes some sense -- you don't want to have to deal with member
postblits if you don't have to. But it also makes it impossible to
intercept copying to do something different (as you would need to do for
this case).
Indeed, something other than the current postblit mechanism looks more
attractive and powerful, even if it isn't as straightforward.
-Steve
