Binding rvalues to ref parameters redux

[bitwise]

On Thursday, 28 March 2019 at 16:07:17 UTC, Nicholas Wilson wrote:
>
>> It seems like a waste to have a keyword that's just an alias 
>> for two others (in = const scope), so why not put 'in' to 
>> better use, like to qualify a ref parameter as accepting 
>> rvalues, or to outright replace 'ref' for rvalue-ref accepting 
>> parameters?
>
> Code breakage.

In this case, I think it's worth it.

Dlang's documentation has warned against using 'in' for YEARS:
https://dlang.org/spec/function.html#param-storage

Any code using 'in' right now deserves to break. (but actually, 
that may not be necessary)

I think 'in' could actually be used without changing it's meaning 
at all. Technically, it is exactly what's needed:

> struct S { }
>
> // void func(const scope ref S s)
> void func(in ref S s) {
>    // ....
>}

If 's' is an rvalue, then the justification for each qualifier 
would be:

const - Modifying 's' has no effect. Allowing it is misleading 
and should be an error.
scope - Temporary arguments should not be allowed to escape, for 
memory safety.
ref - Large objects like 4x4 matrices should be passed by ref for 
efficiency.

So again, 'in' seems like the correct choice for qualifying 'ref' 
parameters as taking rvalues.

As far as using const, I don't really think it's that bad.

If I had to have my rvalues qualified with const, that would be 
fine. To be honest, I don't think I've written any C/C++ code 
that casts const away in years, and would consider it 
unjustifiable. Dealing with legacy code is the only reason I can 
think of that someone may legitimately need to cast const away, 
which is fine though, because if D's const is used with legacy 
code (Extern C or C++ code), you can cast it all you want (to the 
same extent you would in your C code) because you know that 
what's underneath can't possibly be immutable, as C/C++ have no 
such concept.

So finally, I would suggest that rvalues only bind to 'in ref'.