rvalues->ref args

[Manu via Digitalmars-d]

On 13 September 2014 18:02, Dmitry Olshansky via Digitalmars-d <
digitalmars-d at 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 at puremagic.com <mailto:digitalmars-d at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140914/eb886859/attachment-0001.html>