-preview=in might break code

[kinke]

On Monday, 5 October 2020 at 15:25:15 UTC, Iain Buclaw wrote:
> On Monday, 5 October 2020 at 13:27:00 UTC, kinke wrote:
>>
>> Wrt. the concerns about differing ref/value decisions for PODs 
>> across compilers/platforms and thus implementation-dependent 
>> potential aliasing issues for lvalue args: a possible approach 
>> could be leaving everything as-is ABI-wise, but have the 
>> compiler create and pass a temporary in @safe callers if the 
>> callee takes a ref, unless it can prove there's no way the arg 
>> can be aliased. E.g., assuming x87 `real` for Win64:
>>
>> void callee(in real x); // e.g., by-ref for Win64, by-value 
>> for Posix x86_64
>>
>> void safeCaller1(ref x) @safe
>> {
>>     callee(x); // x might be aliased by global state
>>     // for Win64:    auto tmp = x, callee(tmp);
>>     // Posix x86_64: by-value, so simply `callee(x)`
>> }
>
> So then `in` would come with its own semantic, that requires 
> new code to handle, rather than piggy-backing off of `ref`?

It already has its own semantic with -preview=in, so this would 
be a concession for all those raising concerns about 
implementation-dependent aliasing issues. It would just reduce 
new `in` copy elisions for PODs in @safe code and prevent all 
related aliasing trouble (again, PODs only - aliasing could still 
be an issue for non-PODs, but that's not 
implementation-dependent). @safe is already slower due to enabled 
bounds checks even with `-release`, so I could live with it.