const(Class) is mangled as Class const* const

[Jonathan M Davis via Digitalmars-d]

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