On 9/24/2014 7:50 PM, Manu via Digitalmars-d wrote:
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 make similar statements all the time. It doesn't result in action on anyone's
part. I don't tell people what to do - they work on aspects of D that interest them.
Even people who ask me what to work on never follow my suggestions. They work on
whatever floats their boat. It's my biggest challenge working on free software :-)
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.
You kinda put your finger on what the real issue is.
Note that I find gdb well nigh unusable even for C++ code, so to me an unusable
debugger is pretty normal and I don't think much about it. :-) It doesn't impair
my debugging sessions much.
I've also found that the more high level abstractions are used, the less useful
a symbolic debugger is. Symbolic debuggers are only good for pedestrian, low
level code that ironically is also what other methods are very good at, too.
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 :)
No prob. The initiating post was an invitation to a wine festival, and that's
what we have :-)
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,
Why not? What does it harm? And with inlining, pointless refs should be
optimized away.
and auto ref can't possibly know.
Can't know what?
auto ref has never to date produced the semantics that I have wanted.
Please be more specific about what and why.
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.
It seems you are very focused on very low level details. Not knowing
specifically what and why you're focused on ref/value, I suggest the possibility
of taking a larger view, focus more on algorithms, and rely on the inliner more.
Take a look at the asm code generated now and then and see if your worries are
justified.
