-preview=in might break code

[Iain Buclaw]

On Sunday, 4 October 2020 at 21:45:03 UTC, Walter Bright wrote:
> On 10/3/2020 7:08 AM, kinke wrote:
>> The idea is that `in` is explicit, and users of a function 
>> with `in` params should think of such params as `const T& 
>> __restrict__` in C++ terms, which should clarify the potential 
>> aliasing problem. Whether the thing is optimized to 
>> pass-by-value then shouldn't make any observable difference 
>> for the caller.
>
> __restrict__ is a C feature only and never made it into the C++ 
> Standard. I implemented it as a no-op in Digital Mars C. The 
> reason is because it relaxes the rules on what optimizations 
> can be performed in ways that can subtly break code. Very, very 
> few C programmers understand exactly what is going on with it, 
> and sensibly avoid it.
>

I don't think __restrict__ is a good way to reason with expected 
behaviour.  The spec only makes three things clear: No clobber; 
No escape; Copy elision if possible.

In is not ref, and is not restrict.  In is in - a value goes in 
and doesn't come out.