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.

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

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.

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 пишет:
>>
>>> 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. 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.

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

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

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
>

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

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 пишет:
>
>> 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.


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?

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.