Sane API design (AKA C's #ifdef hell)

[Dennis]

On Friday, 17 April 2026 at 13:33:49 UTC, Dejan Lekic wrote:
> My replies were not advocating for the C pre-processor.

I interpreted "D does not offer good solution for this and that 
is where C preprocessor wins" as a call to adopt at least some of 
C's pre-processor features into D.

> They were just to make sure people are aware of the pain we who 
> write bindings to C libraries need to suffer in order to do it 
> right...

I agree, that's why I'm a fan of exploring solutions to that. I 
already mentioned ImportC, Rikki mentioned meta-data based 
generation (https://github.com/rikkimax/ogl_gen) which I have 
used as well. I've also been using my own tool 
(https://dkorpel.github.io/ctod/) for binding generation, and 
recently I've been trying out LLMs. They all have their strengths 
and weaknesses.

> In general, configuration management with D is terrible because 
> DOD (D gOD) thought `version` is enough, and then you see code 
> which first turns version(s) into enum(s), and then you see 
> tons of static ifs in the code.

And this is where my experience differs: the hassle always comes 
from the complexity of the library being constantly changing and 
the upstream headers / meta data being janky. Whenever people 
suggest "if we added version algebra to D we could remove these 
50 lines from druntime" I think "I don't want to remove 50 lines, 
I want to remove the whole 150 000!".

I prefer more automation and less configurations, not more 
advanced configuration management. But that's just how I see it, 
hence my question if you could provide examples of how better 
configuration management would benefit D code bases. I'm 
interested in different perspectives.