On Monday, March 27, 2017 20:41:51 kinke via Digitalmars-d wrote: > On Monday, 27 March 2017 at 20:09:35 UTC, Walter Bright wrote: > > Whichever way it is mangled will gore someone's ox. D went with > > the simplest mangling solution, which is to mangle all C++ > > const pointers as "head const". > > [...] > > I suggest a simpler way - declare the C++ side of the D > > interface in a way that matches the way D mangles it. It's > > always been true that in order to interface D with C++ you'll > > need to be a bit flexible on the C++ side. > > Unfortunately, it's almost always the other way around - D code > trying to interop with one of the gazillions existing C++ libs, > and nobody wants to maintain his own fork with D-compatible glue > interfaces. How often did you use `const T *const` vs. `const T > *` in your C++ headers? ;) I think this would be a tiny change > for D, breaking almost no code and well worth the reduction in > required 'flexibility on the C++ side'.
Realistically, unless D fully supports C++ (which pretty much means that it has to become C++ on some level), you're almost always going to be stuck with some sort of glue layer between D code and C++ code. There's no reasonable way around that. We can work to improve the situation so that more C++ stuff just works when hooking up to D, but we'll never get all the way there, because that would mean dragging C++ into D, which we really don't want. There was talk at one point of trying to declare some sort of extern(C++) const that worked more like C++'s const, but even just that would be a huge mess and would further complicate the already overly complicated situation with const in D. And for that matter, even though D is highly compatible with C code, you still have to worry about maintaining all of the bindings. So, even then, you're still basically dealing with a glue layer to maintain, even if it's just there to tell D about the symbols in C land rather than adding any real code. Any time that D interacts with another language, _someone_ is going to have to maintain some sort of glue layer, even if it's a very thin layer, and to a great extent, I think that eliminating that layer is a pipe dream, though I do agree that improvements to make it thinner would certainly be nice (assuming that the cost isn't too high). Now, as for this particular case with const, I really don't know what should be done. What's currently done _is_ the most correct, but it's also something that really isn't what would be done normally in C++ - at least not outside of templated code. Pointers to const are _very_ prevalent, but const pointers to const really aren't. But I'd also be worried about what quirks and problems we'd end up with if we tried to mangle extern(C++)'s const with semantics that didn't match D's semantics, even if in most cases, it wouldn't matter. Also, in general, unless a C++ function was written to be called from D, I don't know how likely it is to work very well. It definitely _can_ work, but from what I've seen thus far, you tend to need to create C++ wrappers to interact with D code anyway, and if you do that, you just write the C++ functions with the correct constness, and it's no longer a problem. - Jonathan M Davis