On 25 September 2014 11:01, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 9/24/2014 2:44 PM, Manu via Digitalmars-d wrote: >> >> The fact there's only 23 doesn't really mean anything, they're all >> major usability problems. >> I feel like I'm back in the early 90's when trying to iterate on my D >> code. >> These issues have proven to be the most likely to send my professional >> friends/colleagues running upon initial contact with D. >> >> Here's some more: >> >> https://issues.dlang.org/show_bug.cgi?id=12899 >> https://issues.dlang.org/show_bug.cgi?id=13198 >> https://issues.dlang.org/show_bug.cgi?id=13213 >> https://issues.dlang.org/show_bug.cgi?id=13227 >> https://issues.dlang.org/show_bug.cgi?id=13243 >> https://issues.dlang.org/show_bug.cgi?id=11541 >> https://issues.dlang.org/show_bug.cgi?id=11549 >> https://issues.dlang.org/show_bug.cgi?id=11902 **** MASSIVE NUISANCE >> https://issues.dlang.org/show_bug.cgi?id=12163 **** MASSIVE NUISANCE >> https://issues.dlang.org/show_bug.cgi?id=12244 **** MASSIVE NUISANCE > > > Thanks for tagging them. > >> >> The last 3 make debugging of anything but the simplest D code >> practically impossible/pointless. >> >> >> Aside from that though, this somewhat leads back to my second point, >> which is that symdeb issues in the compiler aren't enough. It needs to >> be taken wholistically. >> Cooperation between the compiler and tooling devs need to be actively >> engaged to fix many of these issues. > > > I'm sorry, but this is awfully vague and contains nothing actionable.
The action I'd love to see would be "Yes, debugging is important, we should add it at a high priority on the roadmap and encourage the language community to work with the tooling community to make sure the experience is polished" ;) I recognise that is probably unrealistic, because it seems so few people even use symbolic debuggers at all, that we have very few people interested in working on it. I don't really have a practical solution, but the post topic is 'the worst parts of D', and for me, this definitely rates very high :) An excellent action would be to implement proper scoping in the debuginfo, that would fix cursor movement while stepping, differently scoped local's with the same names causing havoc. And also classes not working. Those are some big tickets from the language side responsible for the most trouble. >> I suspect it's because I rely on far more C++ interop than the average >> D user. I have half a decade of solid experience with D<->C++ interop, >> perhaps more than anyone else here? >> It's not 'all my code', but a sufficient quantity that it pops up and >> bites me almost every day, particularly when I try and write any meta. >> > > I still don't understand what use case is it that pops up every day. What > are you trying to do? Why doesn't auto ref work? auto ref makes a reference out of int and float. There are all manner of primitive types and very small structs that shouldn't be ref, and auto ref can't possibly know. auto ref has never to date produced the semantics that I have wanted. If ref is part of the type, it flows through templates neatly, it is also possible to use app-specific logic to decide if something should be ref or not, and then give that argument without static if and duplication of entire functions, or text mixin.
