-preview=in might break code

[Walter Bright]

On 10/4/2020 3:27 PM, kinke wrote:
> 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).

Ask a random C++ programmer what __restrict__ means. At least it has an ugly 
syntax, which people who don't know what it means will avoid. `in` is a 
gingerbread house.


> 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
> }

That's right, but they *do not* know about `in` introducing such, and there's no 
way to reliably detect 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.
> 
> 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.

I'd be fine calling it `const scope ref`. At least it says what it is doing, and 
its behavior is not implementation defined.

> For those who find that too 
> complicated, well, just don't opt into the preview feature. We'll see how the 
> adoption goes.

Few if any users will notice a problem caused by it. But they're going to hate 
us when they do have a problem in the field with it.

The thing is, I've been working for years on making D as memory safe as we can. 
This feature is a big step backwards.