Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Friday, 28 October 2016 at 21:05:33 UTC, bitwise wrote: On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Any news on this? Hmm. Why did I expect this? -_-
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Friday, 21 October 2016 at 07:56:40 UTC, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Any news on this?
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Saturday, 22 October 2016 at 22:05:54 UTC, Jonathan M Davis wrote: On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote: I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref? That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis With move semantics in mind, I'm wondering if there may be a better word. Currently in D, IIRC, explicit moving can be done through by-value arguments. If you want to move explicitly from an lvalue, you can use D's std.move(lvalue). The downside is an extra blit/init into the rvalue that's returned by std.move. Then, the function that takes the rvalue may blit again in order to store the contents that are being moved in. As an alternative, non-const '@rvalue ref param' could be used...but would it be clear enough to people(seeing non-const @rvalue) that the contents of the argument could potentially be consumed/moved-from?
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote: > I'm ready to participate (but I can't invest too much time at the > moment). Are we going with @rvalue ref? That would certainly be my preference - at least out of what's been discussed thus far. - Jonathan M Davis
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 22.10.2016 03:10, Andrei Alexandrescu wrote: On 10/21/16 5:39 PM, Timon Gehr wrote: On 21.10.2016 09:56, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Nice! Make sure it is orthogonal to const. :) It would be great if you participated. Such a DIP needs you. -- Andrei I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref?
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/21/16 5:39 PM, Timon Gehr wrote: On 21.10.2016 09:56, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Nice! Make sure it is orthogonal to const. :) It would be great if you participated. Such a DIP needs you. -- Andrei
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 21.10.2016 09:56, Ethan Watson wrote: On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Nice! Make sure it is orthogonal to const. :)
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/21/2016 04:47 AM, Walter Bright wrote: On 10/21/2016 12:56 AM, Ethan Watson wrote: I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Great! I, too, will look forward to that. If we get it right, we'll have a prototype of a good DIP to serve as an example for future submissions. By the way, the deadline for looking at https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md and https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md is October 30, please make sure it is as good as it can be before that. Thanks, Andrei
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 21 October 2016 at 06:57, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote: > >> On 10/20/2016 06:23 AM, Ethan Watson wrote: >> >>> Suitable enough for simple functions. But beyond that becomes >>> maintenance hell. >>> >> >> I agree this workaround has a combinatorial problem. >> > > Yes, Ethan made a good point I hadn't thought of. Shoot me! ;)
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/21/2016 12:56 AM, Ethan Watson wrote: I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly. Great!
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote: I think a solid DIP addressing the problem would have a good chance to get traction. I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP. I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/20/2016 2:53 PM, Andrei Alexandrescu wrote: The combinatorial explosion was one core motivation for C++ rvalue references. I think the authors of the would-be DIP would do good to be conversant with that proposal. -- Andrei "However, as the number of free parameters grows (as in bind and function), this solution quickly grows impractical. The number of overloads required increases exponentially with the number of parameters (2N where N is the number of parameters)." Proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html Spec changes: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/20/2016 04:57 PM, Walter Bright wrote: On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote: On 10/20/2016 06:23 AM, Ethan Watson wrote: Suitable enough for simple functions. But beyond that becomes maintenance hell. I agree this workaround has a combinatorial problem. Yes, Ethan made a good point I hadn't thought of. And any DIP on the matter should cover this point (else it will come up again). These sorts of things are why a DIP should be done - to collect all these points in one place. The combinatorial explosion was one core motivation for C++ rvalue references. I think the authors of the would-be DIP would do good to be conversant with that proposal. -- Andrei
Re: Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote: On 10/20/2016 06:23 AM, Ethan Watson wrote: Suitable enough for simple functions. But beyond that becomes maintenance hell. I agree this workaround has a combinatorial problem. Yes, Ethan made a good point I hadn't thought of. And any DIP on the matter should cover this point (else it will come up again). These sorts of things are why a DIP should be done - to collect all these points in one place.
Binding temporaries to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]
On 10/20/2016 06:23 AM, Ethan Watson wrote:
On Wednesday, 19 October 2016 at 10:32:56 UTC, Walter Bright wrote:
Better:
void f(ref Vector v);
void f(Vector v) { f(v); }
f(Vector(10,20,30));
Suitable enough for simple functions. But beyond that becomes
maintenance hell.
I agree this workaround has a combinatorial problem.
Again, lest this got lost: I think a solid DIP addressing the problem
would have a good chance to get traction. We are in a better place than
we used to with handling ref, and also with the general understanding of
the general matter and how it was problematic for C++.
I'm thinking a DIP would work well around the following lines:
* Explain the problem with well-motivated examples.
* Related work and workarounds, most notably "auto ref" in templates.
Explain how "auto ref" is insufficient. Explain how workarounds are
insufficient.
* Propose a semantics that would address the problem. By far the
preferred way is by means of a lowering to existing language. The
obvious lowering is to have the compiler introduce "auto" variables
prior to the call, as follows:
In the call fun(e1, e2), if e1 and e2 are rvalues and fun specifies it
accepts an rvalue by reference for both parameters, the lowering is:
fun(e1, e2)
=>
{ auto __1 = e1, __2 = e2; return fun(__1, __2); }()
There are potential issues with fun returning ref, which the DIP should
address.
* Propose an annotation to indicate the function allows rvalues. What
comes to mind:
(a) Expand the use of "auto ref" to nontemplates. The common objection
to this is we'd have the same syntax express subtly different semantics
(for templates there are two distinct functions generated, and inside
the template it is possible to distinguish between the two). The DIP
should address this objection.
(b) Use an attribute, e.g. void fun(@rvalue ref Vector);
* Discuss how the annotation affects function signature and mangling
(not sure but probably there should be no effect).
* Sketch the changes to the language definitions.
Thanks,
Andrei
