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

[Dominikus Dittes Scherkl]

On Sunday, 13 September 2020 at 18:32:17 UTC, mw wrote:

> But, I'd reflect on my experience so far on compile-time 
> meta-programming in D as a novice user, the big problems are:
>
> -- in D, there are too many choices, with no clear guideline 
> which one is *THE* one to use for a particular purpose: 
> language or library mechanisms? mixin? template? AliasSeq / 
> aliasSeqOf? Tuple? (non-)?-eponymous version of ...?; and even 
> for a particular option, e.g. Tuple!(int, "MA_optInTimePeriod", 
> TA_MAType, "opInMAType"),  there are choices to use either 
> token (int) or string ("MA_optInTimePeriod"). And user does not 
> have a strong guide on which choice is *THE* way to proceed. 
> Each mechanism seems to have / fit a particular purpose, but 
> when you start to use it, you'll probably find there are new 
> problems come-in later, and you want to revisit the choice you 
> made earlier on.
Yes, and each has its limitations and the compiler checks that 
everything is syntactically correct.
>
> By contrast, in C: there is only *ONE* mechanism, i.e. macro,
... where you can put everything including destroying the 
language, and the compiler never sees it and so can't check for 
any kind of correctness.

>
> -- in D, there is no easy way to convert between token <==> 
> string. Given a token, does token.stringof always work to paste 
> with other strings to generate a new token? and given a string, 
> does mixin!"string" always work to be a valid token?
>
> By contrast, in C: there is only *ONE* way: xxx ## yyy.
And you also have no way to see if this gives a valid token, the 
evaluation-order is implementation dependant and still no checks 
anywhere.

>
> -- in D, there is no easy way to see directly the generated 
> source code by the compiler at compile-time, which makes the 
> debug difficult during development.
Yeah, but after you succeed, it is proven by the compiler that it 
is correct,
but your C-macro can fail on anything else you try to apply it.

>
> By contrast, in C: one can easily see the result via: cpp -P 
> foo.h > foo.c
D also provides a mechanism to see the result after lowering.

I'm really happy to not have to deal with write-only macros 
anymore.