On 1/4/12 3:39 AM, Manu wrote:

 * __forceinline ... I wasn't aware this didn't exist... and yes,
despite all this discussion, I still depend on this all the time. People
are talking about implementing forceinline by immitating macros using

mixins.... crazy? Here's a solid reason I avoid mixins or procedurally

generated code (and the preprocessor in C for that matter, in favour of
__forceinline): YOU CAN DEBUG IT. In an inline function, the code exists
in the source file, just like any other function, you can STEP THE
DEBUGGER through it, and inspect the values easily. This is an
underrated requirement. I would waste hours on many days if I couldn't
do this. I would only ever use string mixins for the most obscure uses,
preferring inline functions for the sake of debugging 99% of the time.

Hmmm, I see that the other way around. D CTFE-generated macros are much easier to debug because you can actually print the code before mixing it in. If it looks like valid code... great.

I think the deal with inline functions is significantly more complex. Inlining is the first step in a long pipeline of optimizations that often make the code virtually unrecognizable and impossible to map back to source in a way that's remotely understandable.