On Tue, 02 Jun 2015 22:28:48 -0400, Jonathan M Davis <jmdavisp...@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
