DIP 1014

[RazvanN]

On Tuesday, 2 July 2019 at 23:05:14 UTC, Manu wrote:
> On Tue, Jul 2, 2019 at 5:51 PM RazvanN via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Tuesday, 2 July 2019 at 05:32:07 UTC, Tremor wrote:
>> > [...]
>>
>> After implementing the copy constructor as a substitute for 
>> the postblit, we realized that the fundamental flaw that the 
>> postblit had (automatic copying) would also manifest in the 
>> case of opPostMove; in Shachars' there is no mention what 
>> happens when the source and destination are differently 
>> qualified. I suspect that before implementing the DIP we need 
>> to sort this out and it might be preferable to imlement a move 
>> constructor a la C++ rather then rely on automatic moving.
>
> Wouldn't it just call the opPostMove qualified identical to the 
> type
> that was moved?
> Is it that you can't do qualifier conversions across a move, 
> but you
> might like to? This kinda feels like a slightly separate issue.

It is not a separate issue. Currently, the compiler may perform
a move that co-occurs with an implicit conversion:

struct T { ... }
T fun();
const x = fun(); // a move may occur together with a qualifier 
change

This is valid code. With DIP1014 it becomes invalid since the 
signature of
__move_post_blt is :

void __move_post_blt(S)(ref S newLocation, ref S oldLocation) 
nothrow if( is(S==struct) );

The above case is not even mentioned in the DIP and it should.