Feedback on Átila's Vision for D

Petar Petar
Fri Oct 18 08:28:22 UTC 2019

On Thursday, 17 October 2019 at 23:56:20 UTC, Gregor Mückl wrote:
> On Thursday, 17 October 2019 at 13:16:07 UTC, Petar Kirov 
> [ZombineDev] wrote:
>> The last line of work appears to be in the clang-9 branch: 
>> W.r.t to C++ interop there are 5 areas of development:
>> 1. During the past 3 years there have been a ton of fixes to 
>> extern (C++) (and to a lesser extent extern (C), which was 
>> already close to rock-solid) and nowadays it should be pretty 
>> usable (namespaces, classes and templates work in many cases). 
>> You can directly call much of D from C++ and vice versa. 
>> Obviously there are many D and C++ specific language features 
>> that are not yet/can't be supported, but we're pretty further 
>> along than what we had a couple of years ago. Having all 3 
>> major compilers (first DMD, then LDC and now GDC) be written 
>> half in D and half in C++ is a testament to that. (Actually 
>> now DMD is D-only now, but it was in C++ + D mode for enough 
>> time to force many of the developers at the time to at least 
>> make the subset of extern (C++) that it used fully working.)
>> 2. During the past year some parts of STL had bindings written 
>> to them and tested for Linux, Mac and Windows (which is 
>> surprisingly difficult, due to difference in C++ compilers and 
>> STL implementations): 
>> 3. Having tools like dstep and dpp support C++. As far as I 
>> know both tools support only C header files, but at least for 
>> dpp, Atila has listed C++ as a major planned feature. Work in 
>> area 1. makes 3. now possible. The work of one of GSOC 
>> students made a huge impact for dstep, so it's likely that a 
>> similar tactic for dpp would also help.
>> 4. Automatic C/C++ header generation for D code. There has 
>> been solid progress, but we're probably a couple of months 
>> before having the work finally merged upstream.
>> 5. Making import C++ automagically work has been the holy 
>> grail for many. The author of Calypso has had the unfortunate 
>> task of having to single-handedly work on not only 
>> implementation, but also solving many language-level 
>> challenges like template instantiation, overloading and many 
>> more. Adding insult to injury, the most efficient way to 
>> interface with libClang is with C++ and for they don't 
>> guarantee a stable API, and even break it very often, and D's 
>> frontend is likely worse then that (at minimum it switched 
>> from being C++ only, to D only during the time Calypso was 
>> developed.).
>> I think the best way forward is to get it merged in LDC as 
>> soon as possible - that way at least the burden of supporting 
>> new D frontend and LLVM/clang backend versions could be shared 
>> by other contributors.
> Thank you for the detailed progress report. However, I'm afraid 
> that this doesn't answer the one central question that a 
> potential user would have: which version do I use and where/how 
> do I get it?
> Calypso has been mentioned as a possible path to get easy C++ 
> interop here several times. But the current appearance of the 
> github project does not instill any confidence in people who 
> don't feel especially adventurous.

I don't think that anybody has ever advertised Calypso as 
anything remotely production ready. Like any proof-concept/alpha 
software, it should be used only by people coming the mindset 
that they *will* hit many bugs and they're here to test the 
project, report the bugs and help its development. If you're not 
one of those people you should either wait for the project to 
become ready, or if it's important enough for you to help in some 
other way.

> I'm amazed at the determination that it takes to create 
> something as complex as Calypso. I'd very much like it to 
> succeed.

Yes, I am also extremely impressed by the skills and 
determination of the author, and I think that his approach is the 
only that can offer the best user experience, but I think it 
would be more healthy if people don't come with wrong 

> Semi-OT, I would also like to see the automatic C++ header 
> generation integrated into DMD/LDC/GDC. This would complement 
> C++-to-D interop nicely. There's a pull request for this 
> feature on github that is slowly getting stale. I don't know if 
> it's merely being ignored or whether there are remaining issues 
> with it.

That's point 4. on my list. When it will be ready it would be 
part of all 3 compilers. As far as I know there's more work to be 
done and when the author has free time he will need to push 
forward before we can have his PR merged.

More information about the Digitalmars-d mailing list