reflection based on my experience so far on compile-time meta-programming in D as a novice user: the problems

mw mingwu at
Mon Sep 14 17:40:23 UTC 2020

On Sunday, 13 September 2020 at 18:32:17 UTC, mw wrote:
>>> I end up using C macro to generate D functions, the single 
>>> template is this one:
>>> expected_lookback) __NL__\
>> The most straightforward way to do this in D is with a mixin 
>> template. Something like:

>> mixin template DECL_TA_FUNC(string TA_FUNC, FUNC_INS, 
>> FUNC_OUTS, int expected_lookback)
>> {
>>     bool impl(...)
>>     {
>>         // ...
>>     }

Actually I just realized, that Paul literally means `impl(...)`, 
I have thought `(...)` it's an abbreviation for illustration 

The reason is that it's not easy (or not possible at all! to pass 
two or more sets of variadic parameters[1] to a function in D for 

Well, here Paul give a nice trick to pass them (FUNC_INS, and 
FUNC_OUTS) as template parameters. However, if we take a look of 
the C-macro generated function signature:

bool TA_MACD(double[] inData ,

     // the following 3 is FUNC_OUTS
     double[] outMACD, double[] outMACDSignal, double[] 
outMACDHist ,

     // the following 3 is FUNC_INS
     int optInFastPeriod=default_optInFastPeriod,
     int optInSlowPeriod=default_optInSlowPeriod,
     int optInSignalPeriod=default_optInSignalPeriod) { ... }

I would naturally think this is the most straight-forward target 
function signature I want to generate. And I can do it without 
any trouble at all with C-macro.

But if we compare it with Paul's D solution siganature:

     bool impl(...)  // literally `(...)`  here!

That's the difficulty I have experienced. The natural most 
straight-forward target function signature (that I have in mind 
when I start to program) have become a convoluted work-around in 
D. That's why I cannot figure out how to do it.

Now even with all the suggestions of using `-vcg-ast` or 
`pragma(msg, X.stringof)` debug utilities to help, the mental 
burden from the most straight-forward targeted function signature 
to the actual D-generated function signature is still far away!

Further more, if when people use such generated function, at the 
call-site: e.g.

     return TA_MACD(_prices, macd, macdSignal, macdHist);

If something goes wrong, and the user want to go back and check 
the function definition:

-- C-macro generated as I showed above, v.s
-- D version: bool impl(...)  // literally `(...)`  here!
    or, even with the `-vcg-ast` or `pragma(msg ...)` output

You tell me which one is more clear & helpful to identify the 

So here is my point (4) on the problems of D meta-programming:

-- because of the points (1~3), the resulting D meta-programming 
version is often convoluted, and the code may have very bigger 
distance from the most straight-forward targeted function 
signature one have in mind from the beginning. And this makes 
writing & (and more importantly) reading (by a non-code-author) 
such code difficult.


More information about the Digitalmars-d mailing list