-preview=in might break code

[Steven Schveighoffer]

On 10/4/20 10:08 PM, Walter Bright wrote:
> On 10/3/2020 7:49 AM, 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.
> 
> No, it is not. Because a `const ref` can be changed by another mutable 
> reference to the same memory object. This is defined behavior.

My logic in thinking about it is that the function can't know at all 
that a ref-to-value optimization happened, simply because it cannot 
infer or prove that another argument or a global, or whatever, is 
aliased to that ref (and it can't modify the data via the ref, unlike C++).

But actually, that's not the whole story, and I'm thinking that really 
we can't do that.

A *caller* can know that two parameters are aliased (trivially -- pass 
the same parameter twice), and in that case, expect a certain outcome.

So yeah, we can't do this. Just make `in` always ref, and bind to rvalues.

In a response a few posts up, Mathias says "Perhaps you don't know this, 
but the very first implementation, the one I had when I opened the PR on 
April 3rd actually always used `ref`. It had quite a few issues."

What were those issues? Why can't in mean ref always? Or maybe just bind 
`in ref` to rvalues?

-Steve