rvalue references

[kink via Digitalmars-d]

On Tuesday, 9 June 2015 at 20:25:28 UTC, Namespace wrote:
>> No opinions on the semantics for `in` I proposed earlier? `in 
>> T` would be something like a non-escapable `const auto ref T` 
>> accepting rvalues without codebloat and avoiding the 
>> indirection for small POD types T. Wouldn't that eliminate 99% 
>> of the use cases for `auto ref`, improve readability 
>> substantially and be the solution for all the C++ guys missing 
>> the rvalue-bindability of `const T&`?
>
> 'in' means 'const scope' and 'scope ref' together with 'in ref' 
> was proposed in DIP 36 which was rejected. Let's see if Andrei 
> thinks that my current work is satisfying. I hope so. :)

Can you point me to the justifications for the rejection? It 
should be pretty obvious that something like that is required. 
Personally, I'd go with `ref` being non-escapable by default and 
hence providing implicit rvalue-bindability, and having to use 
`escapable ref` if the parameter may escape and disallowing 
rvalues for these parameters. I know it's never gonna happen, 
it's just what I'd prefer.

I know what `in` currently means. Your proposed `in ref T` syntax 
is imo not much better than C++ `const T&`, so I'd prefer a 
simple and convenient `in T`. Semantics would be identical to 
your `in ref` with the additional optimization for small POD 
types. And for beginners, one could simply describe it as:
'Use the in keyword for a parameter if you're not going to mutate 
it. Don't rely on its identity as the argument may be passed by 
value or reference, whatever seems more efficient for the 
compiler and the target platform.'