__rvalue and Move Semantics first draft - aliasing problem/danger

[Timon Gehr]

On 11/19/24 07:50, Walter Bright wrote:
> On 11/10/2024 9:36 AM, Timon Gehr wrote:
>> I think the main potential trouble is that there is usually an 
>> assumption that there is no aliasing between rvalue arguments.
>>
>> For example, if a compiler backend assumes no aliasing, undefined 
>> behavior might be introduced if one of the arguments is modified and 
>> then the other is read.
>>
>> Of course, we can instead specify that the aliasing is legal (but it 
>> may still be surprising).
> 
> The problem exists anyway.
> 
> https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md
> 
> This has been incorporated, but is only turned on with a switch.

Well, aliasing between `ref` parameters is an expected thing that can 
occur. Backends and users are aware of this possibility. Check out the 
implementation of std.algorithm.swap.

Aliasing between non-`ref` parameters (or across `ref`-ness) is a 
different thing. This can be rather surprising and I think it would 
sometimes lead to undefined behavior with current backends.

So the question is how `__rvalue` will interact with `@safe`, and if it 
is sometimes unsafe, whether there will be a safe variant that 
conservatively moves rvalues in memory to avoid aliasing situations if 
they cannot be precluded.