-preview=in might break code

[Walter Bright]

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.

If such a user uses __restrict__ with a compiler that ignores it, then uses mine 
that enforces it and breaks his code, what happens is that *I* get the blame. I 
can quote the Standard to him all day, but he'll inevitably say "it works with 
Microsoft C, it doesn't work with yours, you are wrong." I know this because 
I've had these conversations with customers that relied on bugs in Microsoft C. 
It's hopeless, so I implement Microsoft C's bugs.

The problem with __restrict__ is that the C compiler is fundamentally incapable 
of detecting buggy uses of it at compile time. Whether those bugs exhibit at 
runtime or not is implementation-defined. It's not a surprise that the C++ 
Standard did not adopt it.

`in` is a nice, friendly looking construct. It looks like pass-by-value, which 
we're all familiar with, and in fact we've trained users to regard it as 
pass-by-value because that's the existing behavior for 20 years. Changing its 
behavior so it *may* introduce memory corruption in very un-obvious and 
un-checkable ways is a very serious problem.