www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - rvalue references

reply "Namespace" <rswhite4 gmail.com> writes:
As far as I know, the problem (or at least one of the biggest 
problems) for rvalue references was that they could escape. Since 
DIP25 is approved and already implemented this problem should be 
solved. Would it be possible to allow rvalues references now? I'm 
just curious what the mindfactory of D has in mind and what the 
scheme for that problem is.
May 12 2015
next sibling parent "Namespace" <rswhite4 gmail.com> writes:
No draft so far?
May 13 2015
prev sibling next sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Tue, 12 May 2015 08:54:15 -0400, Namespace <rswhite4 gmail.com> wrote:


 As far as I know, the problem (or at least one of the biggest problems)  
 for rvalue references was that they could escape. Since DIP25 is  
 approved and already implemented this problem should be solved. Would it  
 be possible to allow rvalues references now? I'm just curious what the  
 mindfactory of D has in mind and what the scheme for that problem is.



Wouldn't DIP69 have to be dealt with first before this happens?
There seems to be some overlap between DIP69 and DIP25.

For example, isn't scope unnecessary for this code after DIP25?

func(scope ref T t) {
     return t; // already illegal per DIP25, no need for scope
}


   Bit
May 13 2015
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Tue, 12 May 2015 08:54:15 -0400, Namespace <rswhite4 gmail.com> wrote:


 As far as I know, the problem (or at least one of the biggest problems)  
 for rvalue references was that they could escape. Since DIP25 is  
 approved and already implemented this problem should be solved. Would it  
 be possible to allow rvalues references now? I'm just curious what the  
 mindfactory of D has in mind and what the scheme for that problem is.



Side note: DIP36 seems to be missing the table with the authors, status,  
etc.

   Bit
May 13 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:

 On Tue, 12 May 2015 08:54:15 -0400, Namespace 
 <rswhite4 gmail.com> wrote:


 As far as I know, the problem (or at least one of the biggest 
 problems) for rvalue references was that they could escape. 
 Since DIP25 is approved and already implemented this problem 
 should be solved. Would it be possible to allow rvalues 
 references now? I'm just curious what the mindfactory of D has 
 in mind and what the scheme for that problem is.



 Side note: DIP36 seems to be missing the table with the 
 authors, status, etc.

   Bit


Huh, DIP36? DIP36 was rejected, but the authors (me and Dicebot) 
are below.

I've heard that DIP69 is [quote]almost dead in favor of 
DIP25[/quote]. That's why I'm a bit confused and would like to 
know the scheme, if any. :)
May 13 2015
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Thu, 14 May 2015 02:56:46 -0400, Namespace <rswhite4 gmail.com> wrote:


 On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:

 Side note: DIP36 seems to be missing the table with the authors,  
 status, etc.

   Bit


 Huh, DIP36? DIP36 was rejected, but the authors (me and Dicebot) are  
 below.


Hmm.. so they are ;)


 I've heard that DIP69 is [quote]almost dead in favor of DIP25[/quote].  
 That's why I'm a bit confused and would like to know the scheme, if any.  
 :)



Makes sense, but if scope is dead, I assume it would have to be removed at  
some point.

So I guess 'ref' could just take rvalues now that it's escape-proof right?

Also, what becomes of the 'in' storage class? being just another word for  
'const' seems like a waste.

If it were up to me, I would say:

'scope' should be removed as a storage class,
'ref' should be left as is, and
'in' should adopt the behavior of 'ref' post DIP25

   Bit
May 14 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:

 On Thu, 14 May 2015 02:56:46 -0400, Namespace 
 <rswhite4 gmail.com> wrote:


 On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:

 Side note: DIP36 seems to be missing the table with the 
 authors, status, etc.

  Bit


 Huh, DIP36? DIP36 was rejected, but the authors (me and 
 Dicebot) are below.


 Hmm.. so they are ;)


 I've heard that DIP69 is [quote]almost dead in favor of 
 DIP25[/quote]. That's why I'm a bit confused and would like to 
 know the scheme, if any. :)



 Makes sense, but if scope is dead, I assume it would have to be 
 removed at some point.

 So I guess 'ref' could just take rvalues now that it's 
 escape-proof right?

 Also, what becomes of the 'in' storage class? being just 
 another word for 'const' seems like a waste.

 If it were up to me, I would say:

 'scope' should be removed as a storage class,
 'ref' should be left as is, and
 'in' should adopt the behavior of 'ref' post DIP25

   Bit


As Andrei said several times (recently here: 
http://forum.dlang.org/thread/scaufixfdyyrbmijgitf forum.dlang.org?page=3#post-mit5lp:241kpt:24
:40digitalmars.com) 
auto ref will take care about rvalue references. I've only hoped 
that I could get a schedule for that or at least a confirmation. 
:)

But interesting question, what will happen with scope, now that 
we have return ref.
May 14 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/14/15 10:15 AM, Namespace wrote:

 But interesting question, what will happen with scope, now that we have
 return ref.


Evaluate its merit once we have everything else in. -- Andrei
May 14 2015
parent "Namespace" <rswhite4 gmail.com> writes:
On Thursday, 14 May 2015 at 17:50:35 UTC, Andrei Alexandrescu 
wrote:

 On 5/14/15 10:15 AM, Namespace wrote:

 But interesting question, what will happen with scope, now 
 that we have
 return ref.


 Evaluate its merit once we have everything else in. -- Andrei


Short and meaningful. Thank you.
May 14 2015
prev sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Thu, 14 May 2015 13:15:34 -0400, Namespace <rswhite4 gmail.com> wrote:

 On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:

 If it were up to me, I would say:

 'scope' should be removed as a storage class,
 'ref' should be left as is, and
 'in' should adopt the behavior of 'ref' post DIP25

   Bit


 As Andrei said several times (recently here:  
 http://forum.dlang.org/thread/scaufixfdyyrbmijgitf forum.dlang.org?page=3#post-mit5lp:241kpt:24
:40digitalmars.com)  
 auto ref will take care about rvalue references. I've only hoped that I  
 could get a schedule for that or at least a confirmation. :)



If I understand Andrei's response correctly though, you will still have to
use 'auto ref' to get ref to bind to rvalues.. no?

So if I'm right about the above, and scope is out, why not just use 'in'  
instead of 'auto ref'?

     Bit
May 14 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
On Thursday, 14 May 2015 at 20:02:29 UTC, bitwise wrote:

 On Thu, 14 May 2015 13:15:34 -0400, Namespace 
 <rswhite4 gmail.com> wrote:

 On Thursday, 14 May 2015 at 16:53:04 UTC, bitwise wrote:

 If it were up to me, I would say:

 'scope' should be removed as a storage class,
 'ref' should be left as is, and
 'in' should adopt the behavior of 'ref' post DIP25

  Bit


 As Andrei said several times (recently here: 
 http://forum.dlang.org/thread/scaufixfdyyrbmijgitf forum.dlang.org?page=3#post-mit5lp:241kpt:24
:40digitalmars.com) 
 auto ref will take care about rvalue references. I've only 
 hoped that I could get a schedule for that or at least a 
 confirmation. :)



 If I understand Andrei's response correctly though, you will 
 still have to
 use 'auto ref' to get ref to bind to rvalues.. no?


Yes, that's what I said. :)
Besides, it would be horrible if rvalues could be bound to normal 
ref.


 So if I'm right about the above, and scope is out, why not just 
 use 'in' instead of 'auto ref'?

     Bit


Don't ask me, I'm just a little light here.
May 14 2015
parent reply "Namespace" <rswhite4 gmail.com> writes:
 Don't ask me, I'm just a little light here.


But I think it's because 'in' means 'const scope' and as you 
said, scope is out. ;)
May 14 2015
parent bitwise <bitwise.pvt gmail.com> writes:
On Thu, 14 May 2015 16:12:36 -0400, Namespace <rswhite4 gmail.com> wrote:


 Don't ask me, I'm just a little light here.


 But I think it's because 'in' means 'const scope' and as you said, scope  
 is out. ;)



Which means 'in' is available! ;)

   Bit
May 14 2015
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 14 May 2015 at 06:56:47 UTC, Namespace wrote:

 On Thursday, 14 May 2015 at 00:12:05 UTC, bitwise wrote:

 On Tue, 12 May 2015 08:54:15 -0400, Namespace 
 <rswhite4 gmail.com> wrote:


 As far as I know, the problem (or at least one of the biggest 
 problems) for rvalue references was that they could escape. 
 Since DIP25 is approved and already implemented this problem 
 should be solved. Would it be possible to allow rvalues 
 references now? I'm just curious what the mindfactory of D 
 has in mind and what the scheme for that problem is.



 Side note: DIP36 seems to be missing the table with the 
 authors, status, etc.

  Bit


 Huh, DIP36? DIP36 was rejected, but the authors (me and 
 Dicebot) are below.

 I've heard that DIP69 is [quote]almost dead in favor of 
 DIP25[/quote]. That's why I'm a bit confused and would like to 
 know the scheme, if any. :)


There's been no official decision, AFAIK. I was just going from 
the impression I got from Walter & Andrei's posts. But `scope` as 
a storage class is still necessary, because there are many more 
kinds of references in D besides `ref`. You can think of `ref` 
implying `scope`. The next steps will be to a) complete the 
implementation of `return ref`, b) extend it to those other 
reference types like pointers, slices, classes and delegates, and 
c) close the holes (see the thread "RCArray is unsafe").
May 15 2015