-preview=in might break code

[Mathias LANG]

On Monday, 5 October 2020 at 17:11:52 UTC, Walter Bright wrote:
>
> The problems come from:
>
> 1. the user not knowing if `in` is passing by ref or not
>
> 2. being "implementation defined" meaning that the user simply 
> cannot know (1) because it can change from version to version, 
> or with changes in compiler switch settings. Not just in 
> switching from one compiler to another (although that's bad 
> enough)
>
> 3. the user would have to look at the disassembly to determine 
> (1) or not, and this is unreasonable
>
> 4. if the function is a template with `in T t` as a parameter, 
> the user cannot know if `t` is passed by ref or not

1. Just like `auto ref`, `in` should be user when the user 
doesn't care whether he gets an lvalue or a rvalue. This means 
that the user either expect no aliasing, or that aliasing does 
not affect the observed behavior.

2. Answered in (1)

3. `__traits(isRef)` works perfectly fine, no need to look at the 
assembly. It's not currently tested though, I'll add it to the 
test suite.

4. The user can know using `__traits(isRef)`. In general, the 
user shouldn't care (see 1), but the ability is there.