I also think writing DIP would be better.

I can tell some reasonable points about 'scope ref'.
- 'in ref' has been allowed from 2.060 (http://d.puremagic.com/issues/show_bug.cgi?id=8105)
- 'scope ref' is still disallowed. ("Error: scope cannot be ref or out")
- 'scope' means "the reference cannot escape from local scope".
  And an rvalue reference cannot escape from passed function. There is consistent semantics.
- 'in' is equivalent to 'const scope' ( http://dlang.org/function.html )
  So, 'in ref' is equivalent to 'const scope ref'.
- Currently 'scope' affects to delegate parameter. In other cases, 'scope' has no meaning.

I recognize that Jonathan had opposed to 'in ref' because it had supported just only "const rvalue reference" (like 'cosnt T&' in C++). In D, 'const' means physical const, so he has thought that mutable rvalue reference should be supported in D.

So, I think 'scope ref' is good proposal against the Jonathan's objection.


Kenji Hara

2013/4/5 Dicebot <m.strashun@gmail.com>
On Thursday, 4 April 2013 at 14:43:26 UTC, Namespace wrote:
On Thursday, 4 April 2013 at 07:52:51 UTC, Dicebot wrote:
After some thinking on topic I come to conclusion that rvalue refs _should_ be "scope ref" and stuff like "ref int f(@temp ref int x) { return x; }" is invalid. I can see no valid use case for such an error-prone case. Contrary, "scope ref" feels just like it was designed for this task, also a good moment to actually define what "scope" means.

I am beginning to like scope ref also. It just fits.
Nice that we agree on that now - but I still miss Kenji's, Walters and Andrei's blessing. Otherwise I think it would be ripe for a pull request. Or there is any difficulty?

I don't know. My opinion has no value here. I may advice to write a DIP that makes more accent on theoretical side of problem - what "scope" currently is, how it combines with ref now, how it should combine, how Andrei's DIP fits in the picture, how it fits overall type system, what are possible code breakage scenarios, what are typical use cases for this feature etc. If such DIP and matching pull request do exist, it is only matter of agreement (with Andrei/Walter) about points stated in DIP.