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 )<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 <http://dlang.org/function.html>2013/4/5 Dicebot <m.stras...@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. >