Binding rvalues to ref parameters redux

[bitwise]

On Tuesday, 2 April 2019 at 23:40:42 UTC, Nicholas Wilson wrote:
> On Monday, 1 April 2019 at 16:43:15 UTC, bitwise wrote:
>> 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
>
> Try 10 months:
> https://github.com/dlang/dlang.org/commit/93411bed24382a08212648c273183d0725cf5d
> and 15 months for
> https://github.com/dlang/dlang.org/commit/71ad1b38d5b5d0a25e383c1dce27e90ed6698f71

Hey, thanks for looking this up. The situation with 'in' was also 
explained to me in a forum conversation. Maybe I'm confusing that 
with seeing the information in the docs. Based on the second 
link, it couldn't possibly have been be more than 15 months ago 
that I got this information, but to be honest, I think 15 months 
still more than enough to support my claim that 'in' has been 
sitting around collecting dust for a long time and should be put 
to good use. Even before the change 15 months ago, it was an 
alias for const, which is arguably useless, and certainly 
unnecessary.

I think this is all beside the point though, since my argument 
has evolved to where I believe 'in' can be used as is, as long as 
the implementation of 'scope' is completed as advertised.

>> Any code using 'in' right now deserves to break. (but 
>> actually, that may not be necessary)
>
> That change is still within our 2 year deprecation period and I 
> think it was not a good move.

I don't understand - are you saying it was already deprecated?

I don't see it here:
https://dlang.org/deprecate.html

Even if deprecating it was just a discussion - are there already 
plans for 'in'?

>> So finally, I would suggest that rvalues only bind to 'in ref'.
>
> This comes down to an opt in vs opt out, 'in ref' (leaving 
> aside the issues with const) mean that bindings and code must 
> be updated to allow use, whereas rvalues not binding to 'out 
> ref' allows immediate use. I'm for opt out.

Was 'out ref' a typo?

In any case, I can think of three ways for a function to accept 
an rvalue:

1) pass by value
2) use an auto ref template
3) use 'ref' parameters and pass in a temporary local variable 
created from the rvalue

#1 would require updates either way
#2 already accepts rvalues, so no changes needed
#3 this would still require updates to remove the temporaries and 
pass the values directly. It would actually be worse because you 
would have to patch all the invocation sites instead of just the 
classes/structs that accept the rvalues

Did I miss any?

I suppose that any new code that calls functions with 'ref' 
parameters could start passing rvalues, but to take advantage of 
this, the function would have had to be written like #3.

Trying to implement this so things "just work" afterward doesn't 
seem like a worthwhile constraint to me. I have a 4x4 matrix 
class, and all things considered, I chose #1.