My thoughts & tries with rvalue references

[kenji hara]

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.strashun at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130405/b6dd456c/attachment.html>