Deprecating this(this)

[Steven Schveighoffer]

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