-preview=in might break code

[Mathias LANG]

On Saturday, 3 October 2020 at 22:55:36 UTC, Andrei Alexandrescu 
wrote:
> On 10/3/20 5:36 PM, Mathias LANG wrote:
>> [...]
>> 
>>  From the caller's point of view, it's also simpler with `in`. 
>> The same function will always be called
>
> Not across long distance changes and platform particulars. This 
> is a very important detail.

This merely sidesteps the question, not actually answering the 
point raised.
Very little, if anything, can resist long distance changes and 
platform particulars.
We don't ban `size_t` from code because adding two values might 
have a different result depending on the platform. We don't ban 
`extern(C)` because someone might use a name that happens to be a 
D symbol and break completely unrelated things.

A templated function with an `auto ref` parameter can lead to a 
different function being called based on your architecture, I 
demonstrated so in my previous message. Regarding long distance 
change, we would have to define what a degree is, and how many 
degrees is long distance. But unless "change" is bound to a very 
specific meaning made to overfit what happens with `in` and not 
`auto ref`, rest assured that both (and probably many other 
languages features) will be affected just the same.

I did a bit of digging on `auto ref`, to supplement this 
conversation. There was one post from Jonathan M. Davies that 
phrased it well:
> With auto ref, you're specifically saying that you don't care 
> whether the function is given an lvalue or rvalue. You just 
> want it to avoid unnecessary copies. That's very different. And 
> auto ref then not only then protects you from cases of passing 
> an rvalue to a function when it needs an lvalue, but it makes 
> it clear in the function signature which is expected.

https://forum.dlang.org/post/mailman.3031.1356562349.5162.digitalmars-d@puremagic.com

I found a few other discussions, including this: 
https://forum.dlang.org/thread/rehsmhmeexpusjwkfnoy@forum.dlang.org (page 6 was quite relevant), and of course https://github.com/dlang/dmd/pull/4717

Much to my surprise, the challenges of parameter aliasing was 
never brought up in any of those topics, because, as quoted 
before, "you don't care whether the function is given an lvalue 
or a rvalue", which conversely means "you don't care if your 
function receives an lvalue or a rvalue". For this to be possible 
without affecting the observable behavior of the function, one 
has to rule out mutation via aliasing.