Is there any good reason why C++ namespaces are "closed" in D?

[Manu]

On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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?

Faster and consistently, sure. But I don't think 'better' is possible.

>From my experience, in many cases, C++ really doesn't express well in
D by direct translation. I tend to do significant massaging of the C++
helper material to improve the experience from D.
Usually C++ libs have a lot of helper material in the form of macros,
little template utilities, inline wrappers, and they can almost always
be expressed more nicely in D with some tweaking.
I often also insert some additional inline D helpers/wrappers nearby
the externs, which help adapt the signatures; ie, apply some
attributes, or make a slice-based API that transforms to ptr+len args,
maybe implement a range helper, that sort of thing.
The goal is to make the API attractive such that a user is compelled
to prefer interacting with the lib from D than from C++.
C++ namespaces interfere with overload resolution in particular, and
that makes this goal harder.

It probably depends on your use. If you're just calling a C++ lib, and
wrap it up in a box for use in your local code, a machine translation
for the API might be fine. I'd call that 'making use of a feature
lib'.
If you are linking to a lib that is a fundamental part of your
application infrastructure, you absolutely must do significant manual
work to make the C++ code express nicely to D, otherwise the
user-experience interacting with the C++ api from D will be worse than
just using C++.
If the C++ experience is better than from D, then D experience ceases
to exist as no case can be made to prefer D over C++, the project is
moot, and I have wasted my time.
The D experience must not just be equal to the C++ experience, it must
typically be substantially better in a variety of ways, and I have
never been able to have such an experience interacting with C++
without making some manual effort towards quality bindings.
The current namespace mechanics put SOOO much more strain on that goal
than is necessary.

One other important feature of quality bindings, is that the binding
itself must be readable and maintainable. The binding itself is the
very first showcase to C++ programmers of how their API's could be
better in D. It must be well organised (like normal D code), and the
current situation with boilerplate invading the works is destructive
toward that end.
Of course, thanks to this namespace situation, when involving with
these hideous workarounds, they are usually objectively NOT better in
D, and C++ programmers do indeed recognise that immediately.