Hi everyone,

I have the pleasure to announce to you all the existence of a modified LDC able to interface directly to C++ libraries, wiping out the need to write bindings:


It's at a prototype stage, but its C++ support is pretty wide already:

 • Global variables
 • Functions
 • Structs
 • Unions (symbol only)
 • Enums
 • Typedefs
• C++ class creation with the correct calls to ctors (destruction is disabled for now)
 • Virtual function calls
• Static casts between C++ base and derived classes (incl. multiple inheritance offsets) • Mapping template implicit and explicit specializations already in the PCH to DMD ones, no new specialization on the D side yet • D classes inheriting from C++ ones, including the correct vtable generation for the C++ part of the class

So what is this sorcery? Let's remind ourselves that this isn't supposed to be feasible:

Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable.

Well.. it is :D
Calypso introduces the modmap keyword, as in:

  modmap (C++) "cppheader.h";

to generate with the help of Clang libraries a "virtual" tree of C++ modules. Then after making Clang generate a PCH for all the headers, the PCH is loaded and classes, structs, enums are placed inside modules named after them, while global variables and functions are in a special module named "_". For example:

import (C++) Namespace.SomeClass; // imports Namespace::SomeClass import (C++) Namespace._; // imports all the global variables and functions in Namespace import (C++) _ : myCfunc, myGlobalVar; // importing the global namespace = bad idea, but selective imports work

Being a prototype, I didn't really pay attention to code conventions or elegance and instead focused on getting things working. And being tied to LDC and Clang (I have no idea how feasible a GCC version would be), it's going to stay like this for some time until I get feedback from the contributors on how this all should really be implemented,. For example Calypso introduces "language plugins", to minimize the amount of code specific to C++ and to make support of foreign languages cleaner and less intrusive, although it of course needs numerous hooks here and there in DMD and LDC.

Calypso is still WIP, but it's in pretty good shape and already works in a lot of test cases (see tests/calypso/), and is almost ready to use for C++ libraries at least. Since C libraries are in the global namespace, it's not a convenient replacement yet for bindings until I implement the Clang module map format. More info this blog post detailing some of the history behind Calypso:


So.. Merry Christmas dear D community? :)

My take on the current talks of "feature freezing" D: the strength of D is its sophistication. The core reason why D fails to attract more users isn't the frequent compiler bugs or regressions, but the huge amount of time needed to get something done because neither equivalent nor bindings exist for most big and widespread C++ libraries like Qt. All these talks about making D a more minimalist language won't solve much and will only result in holding back D, which has the potential to become a superset of all the good in other system languages, as well as bringing its own powerful unique features such as metaprogramming done right. By removing the main reason why D wasn't a practical choice, this will hopefully unlock the situation and make D gain momentum as well as attract more contributors to the compilers to fix bugs and regressions before releases.

Reply via email to