On 13 September 2014 18:02, Dmitry Olshansky via Digitalmars-d < [email protected]> wrote:
> 13-Sep-2014 05:43, Manu via Digitalmars-d пишет: > >> On 13 September 2014 03:14, monarch_dodra via Digitalmars-d >> <[email protected] <mailto:[email protected]>> 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?
