On 11/9/2024 6:38 PM, Richard (Rikki) Andrew Cattermole wrote:
> But it does tell us, that as a language feature it is dependent upon it, to be working correctly, so can't be turned on until then.

By setting the source to S.init after the move, it will work safely.

On 11/9/24 23:44, Walter Bright wrote:
> I'm not sure it's a problem or a danger.
> 
> Timon mentioned the related problem with:
> 
> ```
> callee(__rvalue s, __rvalue s);
> ```
> 
> where s would be destroyed twice. This isn't always detectable:
> ```
> S* ps = ...;
> callee(__rvalue *s, __rvalue(*s));
> ```
> But can be rendered benign with the blit of S.init after the destructor call.

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).

On 11/10/24 00:01, Walter Bright wrote:
> On 11/9/2024 9:37 AM, kinke wrote:
>> Oh, there's at least one problem with the `this(T)` move-ctor signature - C++ interop. C++ doesn't destroy the parameter, because it's an rvalue-ref. The proposed by-value signature in D however includes the destruction of the value-parameter as part of the move- construction. The same applies to move-assignment via `opAssign(T)`. So after calling a C++ move ctor/assignOp with an `__rvalue(x)` argument, the rvalue wasn't destructed, and its state is as the C++ callee left it. Automatically reset-blitting to `T.init` would be invalid in that case, as the moved-from lvalue might still have stuff to destruct.
> 
> We could disallow __rvalue arguments for call to C++ functions?

How do you even call a C++ function that accepts an rvalue reference from D?

If `extern(C++) this(T)` magically matches the C++ move constructor, it seems that additional magic has to be added to all calls in any case to deal with the mismatch.

On 11/11/24 12:31, kinke wrote:
> On Sunday, 10 November 2024 at 17:36:25 UTC, Timon Gehr wrote:
>> On 11/9/24 23:44, Walter Bright wrote:
>>> I'm not sure it's a problem or a danger.
>>>
>>> Timon mentioned the related problem with:
>>>
>>> ```
>>> callee(__rvalue s, __rvalue s);
>>> ```
>>>
>>> where s would be destroyed twice. This isn't always detectable:
>>> ```
>>> S* ps = ...;
>>> callee(__rvalue *s, __rvalue(*s));
>>> ```
>>> But can be rendered benign with the blit of S.init after the destructor call.
> 
> But that's at least already invalid/undefined in your proposal. I've used `callee(lval, __rvalue(lval))` to show that the aliasing problem can occur in valid code too - `lval` isn't accessed lexically after __rvalue'ing it. __rvalue'ing a global variable and checking that the global isn't accessed in the callee is even harder.
> ...

Well I would rather not consider this valid as the last use of the original `lval` may be within the callee after the move. My favorite design would be making `__rvalue` a low-level `@system` operation by default and having the high-level `move` operation actually ensure these things cannot happen.

>> I think the main potential trouble is that there is usually an assumption that there is no aliasing between rvalue arguments.
> 
> It's not just an assumption, it's an implicit guarantee - a by-value parameter is analogous to a local in high-level terms, so of course with its own distinct private memory. Well, until now. :)
> ...

Yup.

>> 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.
> 
> This isn't just a problem with compiler optimizations, but in general:
> 
> ```D
> void callee(const ref S x, S y) {
>      y.bla = x.bla - 1;
>      assert(y.bla != x.bla, "have changed ref via value alias!");
> }
> ```

Yup.

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.

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.