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?
