www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - rvalues->ref args

reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
Please can we move on a solution to this problem?
It's driving me insane. I can't take any more of this! >_<

Walter invented a solution that was very popular at dconf2013. I don't
recall any problems emerging in post-NG-discussions.

Ideally, we would move forward on a design for 'scope', like the promising
(imo) proposal that appeared recently. That would solve this problem, and
also many other existing safety problems, and even influence solutions
relating to other critical GC/performance problems.
Sep 08 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
08-Sep-2014 16:46, Manu via Digitalmars-d пишет:
 Please can we move on a solution to this problem?
 It's driving me insane. I can't take any more of this! >_<

 Walter invented a solution that was very popular at dconf2013. I don't
 recall any problems emerging in post-NG-discussions.

 Ideally, we would move forward on a design for 'scope', like the
 promising (imo) proposal that appeared recently. That would solve this
 problem, and also many other existing safety problems, and even
 influence solutions relating to other critical GC/performance problems.
IMO just legalese auto ref for normal functions and you are all set. The semantics end up to be pretty much the same as c++ const & does (not duplicating the function, like current template-style auto ref). -- Dmitry Olshansky
Sep 12 2014
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 12 September 2014 at 16:48:28 UTC, Dmitry Olshansky 
wrote:
 08-Sep-2014 16:46, Manu via Digitalmars-d пишет:
 Please can we move on a solution to this problem?
 It's driving me insane. I can't take any more of this! >_<

 Walter invented a solution that was very popular at dconf2013. 
 I don't
 recall any problems emerging in post-NG-discussions.

 Ideally, we would move forward on a design for 'scope', like 
 the
 promising (imo) proposal that appeared recently. That would 
 solve this
 problem, and also many other existing safety problems, and even
 influence solutions relating to other critical GC/performance 
 problems.
IMO just legalese auto ref for normal functions and you are all set. The semantics end up to be pretty much the same as c++ const & does (not duplicating the function, like current template-style auto ref).
Yeah, the whole function duplication thing is pretty bad. Auto ref should just create a wrapper that forwards, and the implementation always operate on references. With this approach in mind, auto ref for functions should be trivial, in thé sense that the function is compiled normally as a non template that takes refs, and the compiler only generates code/templates to capture r values.
Sep 12 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 September 2014 03:14, monarch_dodra via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Friday, 12 September 2014 at 16:48:28 UTC, Dmitry Olshansky wrote:

 08-Sep-2014 16:46, Manu via Digitalmars-d =D0=BF=D0=B8=D1=88=D0=B5=D1=82=
:
 Please can we move on a solution to this problem?
 It's driving me insane. I can't take any more of this! >_<

 Walter invented a solution that was very popular at dconf2013. I don't
 recall any problems emerging in post-NG-discussions.

 Ideally, we would move forward on a design for 'scope', like the
 promising (imo) proposal that appeared recently. That would solve this
 problem, and also many other existing safety problems, and even
 influence solutions relating to other critical GC/performance problems.
IMO just legalese auto ref for normal functions and you are all set. The semantics end up to be pretty much the same as c++ const & does (not duplicating the function, like current template-style auto ref).
Yeah, the whole function duplication thing is pretty bad. Auto ref should just create a wrapper that forwards, and the implementation always operat=
e
 on references.

 With this approach in mind, auto ref for functions should be trivial, in
 th=C3=A9 sense that the function is compiled normally as a non template t=
hat
 takes refs, and the compiler only generates code/templates to capture r
 values.
Why the hack? Why not just take a local for the rvalue in the scope that it appears? Generating proxy functions and stuff just makes problems, like taking function pointers of functions, and messes with the debuginfo in very annoying ways. Quality debuginfo is super-important, but D gives it very little attention; we need to move forward on that front, not backwards. auto-ref is a disaster, please don't make it more pervasive.
Sep 12 2014
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
13-Sep-2014 05:43, Manu via Digitalmars-d пишет:
 On 13 September 2014 03:14, monarch_dodra via Digitalmars-d
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote:

     On Friday, 12 September 2014 at 16:48:28 UTC, Dmitry Olshansky wrote:

         08-Sep-2014 16:46, Manu via Digitalmars-d пишет:

             Please can we move on a solution to this problem?
             It's driving me insane. I can't take any more of this! >_<

             Walter invented a solution that was very popular at
             dconf2013. I don't
             recall any problems emerging in post-NG-discussions.

             Ideally, we would move forward on a design for 'scope', like the
             promising (imo) proposal that appeared recently. That would
             solve this
             problem, and also many other existing safety problems, and even
             influence solutions relating to other critical
             GC/performance problems.



         IMO just legalese auto ref for normal functions and you are all set.
         The semantics end up to be pretty much the same as c++ const &
         does (not duplicating the function, like current template-style
         auto ref).


     Yeah, the whole function duplication thing is pretty bad. Auto ref
     should just create a wrapper that forwards, and the implementation
     always operate on references.

     With this approach in mind, auto ref for functions should be
     trivial, in thé sense that the function is compiled normally as a
     non template that takes refs, and the compiler only generates
     code/templates to capture r values.


 Why the hack? Why not just take a local for the rvalue in the scope that
 it appears?
 Generating proxy functions and stuff just makes problems, like taking
 function pointers of functions, and messes with the debuginfo in very
 annoying ways.
Please stop bringing this silly argument. It's an implementation detail, debug-info can be outputted as required obviously. For instance scope(exit) is also lowered to try/finally, yet you still should be able step through the right lines with debugger correctly no problem at all.
 Quality debuginfo is super-important, but D gives it very
 little attention; we need to move forward on that front, not backwards.

 auto-ref is a disaster, please don't make it more pervasive.
It was just poorly implemented and only for templates. I don't see how having a different name would help us reach the same effect. -- Dmitry Olshansky
Sep 13 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/14, 1:02 AM, Dmitry Olshansky wrote:
 It was just poorly implemented and only for templates. I don't see how
 having a different name would help us reach the same effect.
auto ref + static checking + minimal dynamic checking = win Andrei
Sep 13 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
What is so bad about producing an implicit temporary? Why are people so
excited about these wildly complex solutions, when the direct solution is
so simple? I've obviously missed something.
On 14 Sep 2014 05:30, "Andrei Alexandrescu via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 9/13/14, 1:02 AM, Dmitry Olshansky wrote:

 It was just poorly implemented and only for templates. I don't see how
 having a different name would help us reach the same effect.
auto ref + static checking + minimal dynamic checking = win Andrei
Sep 13 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/14, 8:49 PM, Manu via Digitalmars-d wrote:
 What is so bad about producing an implicit temporary? Why are people so
 excited about these wildly complex solutions, when the direct solution
 is so simple? I've obviously missed something.
The conversion may end up escaping the address of a temporary. -- Andrei
Sep 13 2014
prev sibling parent "IgorStepanov" <wazar mail.ru> writes:
On Saturday 13 September 2014 at 19:29:54 UTC, Andrei 
Alexandrescu wrote:
 On 9/13/14, 1:02 AM, Dmitry Olshansky wrote:
 It was just poorly implemented and only for templates. I don't 
 see how
 having a different name would help us reach the same effect.
auto ref + static checking + minimal dynamic checking = win Andrei
When I working on a library AA implementation (druntime#934), I have faced a problem: I defined special function-factory, which creats AA instance. auto aaLiteral(Key, Value, T...)(auto ref args) { return AssociativeArray!(Key, Value)(args); } struct AssociativeArray(Key, Value) { this(T...)(auto ref T args) { ... key = args[0];//schematically, IRL key stored into special Entry structure, which stored into hash-table } Key key; } Now we define struct with postblit, and pass it into aaLiteral. struct Foo { this(int) { writeln("C"); } this(this) { writeln("P"); } ~this() { writeln("D"); } } auto aa = aaLiteral!(Foo, int)(Foo(1), 2); This expression expands to the next call chain: aaLiteral | create Foo, prints C, Foo passed by-value AssociativeArray.this() | pass Foo by ref, because aaLiteral parameter is a l-value key = args[0]; | call postblit, because compiler lost information about what args[0] was a r-value When human see this code, he see, that we can avoid one postblit and one destructor call and store passed Foo instance directly into "key" field. Have you any idea, how we can resolve this trouble and pass constructed instance without excess postblit calls without/with language changes.
Sep 14 2014
prev sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 September 2014 18:02, Dmitry Olshansky via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 13-Sep-2014 05:43, Manu via Digitalmars-d =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On 13 September 2014 03:14, monarch_dodra via Digitalmars-d
 <digitalmars-d puremagic.com <mailto:digitalmars-d puremagic.com>> wrote=
:
     On Friday, 12 September 2014 at 16:48:28 UTC, Dmitry Olshansky wrote=
:
         08-Sep-2014 16:46, Manu via Digitalmars-d =D0=BF=D0=B8=D1=88=D0=
=B5=D1=82:
             Please can we move on a solution to this problem?
             It's driving me insane. I can't take any more of this! >_<

             Walter invented a solution that was very popular at
             dconf2013. I don't
             recall any problems emerging in post-NG-discussions.

             Ideally, we would move forward on a design for 'scope', like
 the
             promising (imo) proposal that appeared recently. That would
             solve this
             problem, and also many other existing safety problems, and
 even
             influence solutions relating to other critical
             GC/performance problems.



         IMO just legalese auto ref for normal functions and you are all
 set.
         The semantics end up to be pretty much the same as c++ const &
         does (not duplicating the function, like current template-style
         auto ref).


     Yeah, the whole function duplication thing is pretty bad. Auto ref
     should just create a wrapper that forwards, and the implementation
     always operate on references.

     With this approach in mind, auto ref for functions should be
     trivial, in th=C3=A9 sense that the function is compiled normally as=
a
     non template that takes refs, and the compiler only generates
     code/templates to capture r values.


 Why the hack? Why not just take a local for the rvalue in the scope that
 it appears?
 Generating proxy functions and stuff just makes problems, like taking
 function pointers of functions, and messes with the debuginfo in very
 annoying ways.
Please stop bringing this silly argument. It's an implementation detail, debug-info can be outputted as required obviously. For instance scope(exit) is also lowered to try/finally, yet y=
ou
 still should be able step through the right lines with debugger correctly
 no problem at all.
It frustrates me that people can say this is a silly or trivial argument when myself and everyone I know who I've introduced to D consider it the single biggest sign of language immaturity that still remains. I'm confident the weak debug experience has a strong inhibiting influence on D adoption. The debug experience feels... amateur, at best. It frustrates me on a daily, perhaps hourly basis. I tolerate it because I have hope for D, but I'm in the minority among my industry peer group. I still can't inspect the contents of a class, static/globals, inspect the values of locals repeated in separate scopes, or step through the code in the expected sequential fashion without the cursor jumping around somewhat randomly. I don't know another language that's expected to be taken seriously with such a careless attitude taken towards debugging, and I wonder if your comment may be indicative of the problem. It's not an implementation detail. If a features design is incompatible with a quality debugging experience, it should be considered just as much a real problem as any other detail, and it definitely needs to be considered more seriously than it generally has in the past. Implicit wrapper functions sound like a debug nuisance, they create an additional step-in/step-out sequence, and if they begin appearing on random functions while quickly stepping through code, I can imagine many accidental mis-steps. But regardless of that, you skipped my first and primary point, that it's also semantically complicated (what do you get when you take a function pointer?). It's just a hack to do what could easily be done directly; produce an implicit temp at the callsite. Quality debuginfo is super-important, but D gives it very
 little attention; we need to move forward on that front, not backwards.

 auto-ref is a disaster, please don't make it more pervasive.
It was just poorly implemented and only for templates. I don't see how having a different name would help us reach the same effect.
It's explicitly a template concept. 'auto' is in the same sense also a template concept. I'm not suggesting auto ref by a different name, I'm just suggesting to just make rvalue temporaries work like people expect, which also seems much simpler semantically, and I imagine probably in terms of implementation too= ?
Sep 14 2014