-preview=in might break code

[Walter Bright]

On 10/4/2020 11:37 PM, Iain Buclaw wrote:
> 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.

https://dlang.org/spec/function.html#parameters says:

"in The parameter is an input to the function. Input parameters behaves as if 
they have the const scope storage classes. Input parameters may be passed by 
reference by the compiler. Unlike ref parameters, in parameters can bind to both 
lvalues and rvalues (such as literals). Types that would trigger a side effect 
if passed by value (such as types with postblit, copy constructor, or 
destructor), and types which cannot be copied, e.g. if their copy constructor is 
marked as @disable, will always be passed by reference. Dynamic arrays, classes, 
associative arrays, function pointers, and delegates will always be passed by 
value, to allow for covariance. If the type of the parameter does not fall in 
one of those categories, whether or not it is passed by reference is 
implementation defined, and the backend is free to choose the method that will 
best fit the ABI of the platform."

The salient points are "may be passed by reference", and "whether or not it is 
passed by reference is implementation defined". The trouble with passing by 
reference is when there are other live mutable references to the same memory 
object. Whether mutating through those references mutates the in argument is 
"implementation defined".

That's the problem with `in`. It's not an issue of a shortcoming in DMD.