Idea/Problem

Ok, I know this will probably not happen, but I like D, and I'm going to give it a chance in hopes that I'll be able to convince you why you must do that. Now, let me start by saying that I do understand how hard it is to write a parser for a programming language, let alone C++. However, I will try to explain the reason that the trouble is more than worth it as, it will solve D's 2 biggest problems and complains that people have and not use it.

So let me first start by saying that I think that the D language is the best language that we currently have. While not without its flaws and things that could be massively improved, it's still better than the second best, which is C++. However, D has a very big disadvantage, which is library support. A lot of big and powerful libraries are written in C++ and while there is the ability to manually create the bindings, it can be a real pain to manually make it for big projects and having to keep up with every update (especially major version ones).

Now, you might tell me that all that aren't something new, and you already knew them, but what I'm going to present is that, the only thing that stops D from not only been more popular than it is, but also, been the most used language that there is out there, is a full compatibility with C++! Yeah, I know that it sounds just a bold theory, and you may deem that the risk isn't worth the trouble but, let me ask you one thing. What's the biggest reason D hasn't caught up with big languages? What is the number one complaint that people make about D (the garbage collector is number 2)? Yes, libraries!

Now, D has "importC" and, lots of C++ libraries have C bindings, but the problem is, C doesn't have classes and, you will need to do manual work to create a "D way" of using the library. Also, not every C++ library has C bindings. For example, Louvre does not! If I want to use it from D, I have to:

• Wait for it to create C bindings (and hope they are maintained in the future)
• Manually port the library myself. Which also includes porting other C++ libraries because I will get start with the weston-example that they showcase in their repos.

Improvements

Implementing a C++ parser will have the following advantages:

• C++ libraries will be able to natively been used in D. This includes "macros" and templates that have not been initialized in the actual library and would need an additional initialization from the project that would use them (making the process even more tedious, slow and overall annoying).

• C++ and D code will be able to be combined, giving the ability for any C++ project to more easily and smoothly get fully transit to D. That will bring even more popularity and trust to the language.

• C++ has smart pointers, which means that we will be able to use C++'s standard library for performance sensitive projects, solving D's number 2 complain (which is the garbage collector) and giving even more trust to people to see D as a real competitor that can get the place of C++.

Implementation

First, such project will require a great knowledge of the D compiler and great skills of writing an efficient parser. That's why, if anyone is to do it, it better be the DMD contributors. Second, this is something that will take time, so I believe that the best approach is to try parsing some real libraries, keep improving the parser little by little. Implement, test, fix bugs, test, and repeat! Let's start by the STL library (so we can use the smart pointers as fast as possible) and then, move to more common and big libraries. With steady work, in 2–3 years, we will hopefully have a fully working C++ parser without any bugs. Or at least one that can parse the biggest and most important C++ libraries.

On Saturday, 14 June 2025 at 11:39:01 UTC, rempas wrote:

Oh and something I forgot to say. A small parser would of course mean a preprocessor. Now, this gives one more advantages of not requiring an external C/C++ compiler (both for C and C++). This will also give us the ability to be able to not require extra files and been able to add the headers in the D files. Something like the following:

importC <gtk/gtk.h>; // Header, as a C file (including C11 features)
importCXX <iostream>; // Header, as a C++ file
importC cpp_module; // C++ module (no reason for the two "XX" in the end as, C has no modules!)

void main() {
   std.cout << "Hello from C++'s print function!\n";
}

On Saturday, 14 June 2025 at 11:39:01 UTC, rempas wrote:

I think the best way forward would be taking advantage of the recent work on SWIG. Their last major release added experimental support for C: https://swig.org/Doc4.3/C.html#C

On Saturday, 14 June 2025 at 11:47:38 UTC, rempas wrote:

importC <gtk/gtk.h>; // Header, as a C file (including C11 features)
importCXX <iostream>; // Header, as a C++ file
importC cpp_module; // C++ module (no reason for the two "XX" in the end as, C has no modules!)

void main() {
   std.cout << "Hello from C++'s print function!\n";
}

Most of the IT world agreed that even though C++ is quite popular language, at the same time it has very bad designed.
And they want to move to something else.

Some fields are moving to Go, others to Rust.

Also companies are spending a lot of effort to provide solutions to simplify this transition.
Auto transpilers from C++ to Rust by DARPA and others, Carbon by Google and Apple presented C++ interop to simplify the transition to Swift.

Having C++ interop will be cool now if it will be ready - currently it will be a huge benefit for the language.
But starting developing it now I think will be waste of resources - and moreover D doesn't have these resources even for crucial parts. And for sure no resources for such experimental things.

And also there are other approaches - several languages have very nice C++ interop.
There are projects in Python, R, Julia, Swift, Rust - they have different approaches from automatic bindings generators (cbindgen) to the seamless integrations (Rcpp).

So if you really want compiled language with C++ interop I would suggest to check Swift.

DLang doesn't have a good parser for tooling, nor does it have a good LSP for D's features, and you want it to have a builtin C++ parser?

I suggest we first ensure that D has good tooling for D.., then eventually somebody can begin the work on a C++ parser (even tho it's imo a waste of time.., but what ever..).

On Saturday, 14 June 2025 at 14:37:19 UTC, Lance Bachmeier wrote:

That seems interesting! In general, it would be nice if we lived in a world where there would be a common IR and backend and languages would just target that, allowing you to use any symbol from any language.

On Sunday, 15 June 2025 at 12:46:09 UTC, rempas wrote:

In the case of C, C++ and D (and many others) that is exactly what is happening. They share the same backend.