Hacker News Reader

Comment by WalterBright | Hacker News Reader

D is taking a different approach. D is getting a builtin C compiler (called ImportC) that is a from scratch C compiler, now in prototype form.

https://dlang.org/spec/importc.html

It works by having an extra module called cparse.d

https://github.com/dlang/dmd/blob/master/src/dmd/cparse.d

which parses Standard C. The lexer and semantic routines of the D compiler are then tweaked to support C semantics. The same optimizer and code generator is used.

As a side effect of using the D compiler's innards, ImportC can do things like handle forward references, and even execute C code at compile time!

View on HN

I miss playing with D. It looks like you've done a lot of neat stuff recently, but I just don't have a project that I can use it for. I remember being thoroughly impressed with its metaprogramming capabilities in college when I was working on dproto.

This is getting super-weird, love it!

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!

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

The reasons for ImportC are:

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.

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.

Reply on news.ycombinator.com