Should 'in' Imply 'ref' as Well for Value Types?

[Bolpat]

On Friday, 4 May 2018 at 09:34:14 UTC, Jonathan M Davis wrote:
> [...]
> It's actually not infrequent now that in C++, you want to pass 
> stuf by value rather than const& precisely because move 
> semantics can be used to avoid copies. So, it's not at all 
> necessarily the case that passing by ref is the efficient thing 
> to do. It's heavily dependent on the code in question.

I once proposed that `in` can mean `const scope ref` that also 
binds rvalues.
https://github.com/dlang/DIPs/pull/111#issuecomment-381911140
We could make `in` be something similar to `inline`. The compiler 
can implement it as stated above (assign the expression to 
temporary, reference it), or use copy if copy is cheaper than 
referencing.

> So, even if we were designing in from scratch, making ref would 
> be a questionable choice. However, even if we all agreed that 
> it would be desirable, such a change would break a large 
> percentage of code that currently uses in, because any code 
> that passes an rvalue to a function taking its argument as in 
> would then break. So, any attempt to change in to include ref 
> would have to have some sort of deprecation path to avoid code 
> breakage. But given how annoying it would be to have in be ref 
> by default due to how that affects rvalues, I'm willing to bet 
> that most programmers would not be at all happy with such a 
> change, regardless of how well the transitition was handled.

Yes. Therefore the idea above. It will break much less code if 
any.