rvalue references

[bitwise via Digitalmars-d]

On Tue, 02 Jun 2015 22:28:48 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:
> Where on earth did you get the idea that in was introduced in 2.060?

DIP36:
"in ref has been allowed from 2.060 :  
http://d.puremagic.com/issues/show_bug.cgi?id=8105"

Reading it more carefully this time, I understand what it's saying now =(

> And folks _love_ using in, because they view it as the opposite of out.

To be symmetrical with 'out' shouldn't 'in' == 'const scope ref'?

> Almost always, it's really just const, since scope really only applies
> to delegates at this point, but in is used _heavily_ by many folks in
> the D community.

I still think that it could be put to better use than an alias for const.

> I keep telling folks not to use in, because scope isn't well-defined  
> yet, so who knows what's going to happen when we _do_ try and define it  
> properly, but folks keep using it anyway.

Exactly my point, because it's awesomely convenient, which is why it should
have a more useful meaning :)

> We can't just change the meaning and expect it not to break code. That's
> part of what's going to be so ugly about finishing scope. And there are
> folks who use in fully understanding the risks under the assumption that
> scope will be defined in a way that does what they want. So, many folks
> are relying on in being equivalent to const scope, and changing it to
> mean something else is just plain a bad idea.

I have seen a lot of posts on these forums about people being tired of
breaking changes in D, and I understand that, but I believe 'in' should be
an exception. It's kind of a 'beta' feature, and people should expect that
it's subject to change, especially considering that googling 'dlang in ref'
yields your warning as the second result :)

"1. Don't use in."

Anyways, moving forward with the assumption that the meaning of 'in' will
not change, I still don't understand. Why couldn't 'in ref' be allowed to
accept rvalues in addition to 'auto ref'?

   Bit