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



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