I admit it's been fun! My old C compiler (Datalight C) works well, but its coding practices are severely outdated. I wanted to see how it would look using modern practices.
P.S. I wouldn't be in the business if it wasn't fun.
A decent subset of D programmers have used C and have been majorly bitten by it before, so it's definitely not a marriage of love put it that way. ImportC is, in my view, about optics and a little convenience - using C with D is already trivial if you understand how C works, ImportC just makes it offensively easy to do.
There are some less theoretical things too, i.e. no more keeping kernel headers up to date (apart from ones that use inline ASM that we have to be careful with).
With ImportC, D will be one of the better and non-hackier ways to interface C with other languages - i.e. introspection and metaprogramming but in a real language rather than some brain-dead DSL
1. It's no longer necessary to translate .h files to D to interface with C. While doing the translations isn't hard, it is tedious, and if there are a lot of .h files it becomes a barrier.
2. .h files get updated over time, and correspondingly updating the D files is error prone. It's much more effective to just compile the new .h files.
3. It is not necessary to even create a .h file - just compile the .c file with ImportC and D will access it just like any other module. D will even inline the C functions in it.
4. Use it as a standalone, small and fast, C compiler.
I'm glad D is finally delivering on its promise. I remember looking at it years ago disappointed that "you can use C from D!" meant writing and maintaining wrapper libraries for every damn thing.
One assumes it is because C is so hard to rid ourselves of because POSIX (etc) that you're even entertaining this idea?
I mean, "it's fun" could also work as motivation, I guess.
I'm just curious!