Debugging mixins - we need to do something

[Manu]

TL;DR, debugging is critical and neglected. Mixin is worst offender.

So, string mixin breaks the debugger. All of a sudden there is code
that's executing that doesn't exist anywhere. We need a solution to
this problem...

As I and others have suggested before; mixin expansion should emit a
`[sourcefile].d.mixin` file to the object directory, this file should
accumulate mixin instantiations, and perhaps it would be ideal to also
emit surrounding code for context.

The debuginfo should point into that file when compiling mixin code,
so that it's possible to step and inspect within the mixin.

I initially imagined an 'expanded' copy of the file would be cool, but
that doesn't work when mixins are driven by template args, since the
expansion may be different for every instantiation of the surrounding
code.

There has been lots of chatter in the past, can we prioritise it?
It would help me a lot.


Some background on this issue: (TL;DR, don't read)

D's biggest draw for me is it's powerful meta, and ability to
obliterate a huge quantity of typical C++ boilerplate. As C++
continues to close the gap, this becomes more and more the defining
feature, and probably the primary basis for an argument that you might
make to switch a C++ workflow to D. (closely followed by modules and
build-times)

Most uninterested and/or unopinionated people I've interacted with
recently have agreed that D feels 'pretty good', and they'd be willing
to explore it further if there was a compelling argument.

The focus of resistance in my recent experience has been related 90%
to tooling. In particular, IDE integration, and debug experience. (the
other 10% being implementation issues in extern(C++), which I've been
working to improve)

>From my own experience over the last decade, there is a critical
tension between this core value proposition; which is meta and
boilerplate-reduction vs debugging experience, which is also critical
(and neglected).

I think the state of this tension is the most likely point where a
case for D will fail with my particular set of colleagues.
While I might balance that boilerplate reduction and code simplicity
is worth the trade, they will argue (and I think they will win) that
the fact you practically lose the ability to debug your code when
there is meta nearby is very bad indeed.

I think this is a high-importance ticket. I have absolutely no idea
where to start with this, and I don't have anywhere near enough time
to put towards my current initiatives (extern(C++) stuff).

Is anyone interested in this issue?