-preview=in might break code

[kinke]

On Sunday, 4 October 2020 at 21:45:03 UTC, Walter Bright wrote:
> 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.

And yet all major C++ compilers support it one way or another 
(AFAIK, just for more aggressive optimizations though, no need to 
check for overlaps).

Anyway, I probably shouldn't have brought up __restrict__ - 
simply because every D dev should already know about aliasing 
pitfalls wrt. regular refs:

int foo(const ref int a, ref int b)
{
     b = 123;
     return a;
}

void main()
{
     int a = 0;
     assert(foo(a, a) == 0); // oops, aliasing
}

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

I've been unhappy about the wasted potential for `in` ever since 
working on the ABI details of LDC, and new `-preview=in` is 
something I've wanted for years. Again, the aliasing issue should 
be quite easily avoided by imagining `in` params as `const scope 
ref` at the call sites. For those who find that too complicated, 
well, just don't opt into the preview feature. We'll see how the 
adoption goes.