-preview=in might break code

[kinke]

On Sunday, 4 October 2020 at 20:06:49 UTC, Iain Buclaw wrote:
> If I'd be pressed to bullet point it, I'd put down the 
> following.
>
> When an parameter is annotation with `in`:
> - The parameter is not modifiable.
> - All memory reachable from the parameter can not be clobbered 
> (overwritten).
> - The parameter does not escape.
> - Copy constructors are elided by passing by-ref.
> - Other forms of copy elision may occur if doing so does not 
> change program behaviour.
>
> Is that simple enough for an end-user?

I think that's a pretty good summary, although I'd loosen point 2 
to the object itself, not all memory reachable from it.

The main problem people seem to be focusing on in this thread is 
point 2, the aliasing issue. Firstly, I think people need to 
realize `-preview=in` is absolutely not about being compatible to 
previous semantics, but about entirely new semantics for `in`. 
Secondly, as the potential aliasing problem regards the callers, 
not the callee, a simple rule of thumb should be something along 
the lines of: "If you wouldn't pass the lvalue arg to a `const 
scope ref` parameter due to aliasing concerns, then don't pass it 
to `in` either without an explicit copy."