-preview=in might break code

[Steven Schveighoffer]

On 10/3/20 11:41 AM, Joseph Rushton Wakeling wrote:
> On Saturday, 3 October 2020 at 14:49:03 UTC, Steven Schveighoffer wrote:
>> `in ref` is a reference, and it's OK if we make this not a reference 
>> in practice, because it's const. And code that takes something via `in 
>> ref` can already expect possible changes via other references, but 
>> should be OK if it doesn't change also.
> 
> Is that still OK in a concurrent or multithreaded context?
> 
>      void foo (in ref bar)
>      {
>          // does something which may yield, and
>          // another context can change value
>          // underlying `bar`
>          ...
> 
>          // result of this writeln will now depend
>          // on how the compiler treated the `in ref`
>          writeln(bar)
>      }

This is not any different than calling a function which has a reference 
to the data elsewhere. In other words, it's not necessarily the function 
itself that changes the data, it could be changed outside the function. 
You don't need concurrency to do it.

But it's not impossible to define this:

"when accepting a parameter by `in ref`, one cannot depend on the value 
remaining constant, as other references to the data may change it. The 
compiler can also decide to pass an `in ref` parameter by value for 
optimization reasons, so one cannot depend on the parameter changing 
through a different alias."

That's essentially what `in` means in this preview switch. But the 
problem really is that `in` means something else today, and there is 
already a lot of code that expects that meaning.

-Steve