-preview=in might break code

[Iain Buclaw]

On Monday, 5 October 2020 at 09:49:21 UTC, Walter Bright wrote:
> 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.

I think we can all agree that the wording needs to be improved.

Regarding the last sentence (If the type does not fall in one of 
those categories...), if there's no explicit saying so, I take 
that to mean do nothing unless you can guarantee that there'd be 
no change in program behaviour.  Which may as well be as good as 
being equal to do nothing.

There's no advantage to passing the remaining types not 
explicitly named in the spec using ref semantics anyway.  "In" 
parameters could be forced in memory, but again with a dubious 
benefit of doing so.