On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote:
The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility.
Why would you write bindings if the computer can do it for you, better, faster and consistently?
That's the idea behind DPP. You can just #include C headers and they will be translated before compile time. This is very helpful with projects like HDF5 that consider it acceptable in a minor release to replace a function with a macro.
Wrappers are a bit different. In time C++ will follow.
Not only that, who do you think even writes bindings for libraries? Most bindings are done by the community for libraries to other languages. How many companies do you know have bindings for their C/C++ libraries for D, that maintains them?
We do for a few things - for other peoples' libraries not our own. But it would be better not to have to write bindings at all.
damn hell no. That's what modules are for. So why are you trying to implement namespaces in D under the guise of C++ name mangling.
I don't think either Manu or Atila want to be able to sneak in namespaces by the backdoor. They just want to be able easily to control namespace mangling of C++ linkage symbols.
What extern(C++) should be used for is allowing you
to call C++ code from D, not to be able to format C++ code into D. The only problem you have with breaking code up into multiple files is that it isn't 1:1. That's not a technical problem, it's a problem of conflicting personal opinion. If it's not 1:1, who cares? If some some odd reason you have two namespaces in one file in C++, odds are they are probably separated in that one file anyway. If not and for some reason the the code has multiple namespace definitions smashed together into one file, flip-floping between namespaces. That's not D's problem to fix the project's poor organization method.
For automatically translated bindings I think that the request is not unreasonable because there's considerable value in being able to just #include C++ headers as you can already with C headers and just call the C++ code from D. D doesn't have libraries? Well it's got 1500 on code.dlang.org plus C and C++ libraries. What is it you think is missing? That's a good retort!
I understand from Atila present choice just makes it a lot more complicated, not impossible.
