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

[Q. Schroll]

On Saturday, 5 May 2018 at 15:39:19 UTC, Jonathan M Davis wrote:
> On Saturday, May 05, 2018 15:22:04 Bolpat via Digitalmars-d 
> wrote:
>> 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.
>
> Having ref of any kind accept rvalues is a highly controversial 
> issue, and it may or may not ever be in the language. If it's 
> added, then at that point, whether it makes sense to make in 
> imply ref could be re-examined, and maybe at that point, doing 
> so would make great sense. But as long as ref does not accept 
> rvalues, it really doesn't make sense. It would break too much 
> code and would be far too annoying to use in many, many cases 
> where it is currently commonly used.

I never suggested some spelled out `ref` should bind rvalues. 
Having explicit `ref` bind rvalues is a mistake C++ did and it 
confuses the hell out of people.

For clarification:
`in` should mean for the called function that it may only "look 
at" the information for decisions, but not "touch" it. In this 
sense, not only modifying, also copying or leaking it are a forms 
of touching. Note that objects of a non-copyable types can be 
looked at.
This is how I came to what `in` naturally must mean.
It must mean `const`. It must mean `scope`. It must mean 
referencing, but not in the restrictive way of `ref`, but in the 
permissive interpretation, so it may bind rvalues, too.
For the caller, `in` basically is `const scope` with guaranteed 
no copying.

So, `in` should not imply `ref`, it should imply referencing, 
which is not the same thing.
`in` and `ref` could be combined, so that the restrictive 
character of `ref` does its job, but I'd favor not to allow that 
(similarly `out ref` is not allowed). If you want `const scope 
ref`, spell it out. I'd assume the cases where you want to allow 
lvalues only are rare. They well may exist, so it's good to be 
able to express them.