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

[Laeeth Isharc]

On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote:
> 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.

Would it be inaccurate to make a distinction between bindings and 
wrappers ?  It's always going to be less pleasant to call even C 
bindings from D then an idiomatic D wrapper written on top.

But if you have automatically generated bindings then you can put 
the effort into the wrappers and it's easier to do the latter 
incrementally.

And being able to use a library at all even if slightly 
unpleasantly without having to pay a big price up front beats 
having no choice.  At least for us the sequencing of cost matters 
more than the total cost, and the calendar time element of cost 
to being able to write a passable and useful first version is 
more important than the pecuniary element.

We have many more people who are not C++ programmers but express 
their ideas in D then we do people who know C++ pretty well.

BTW I almost think the D Foundation should organise a library 
wrapping as a service marketplace ;). Lots of people in the 
community are open to remote work part or full time.  But the 
cost is in finding the right people and also to some extent 
supervising and organising the design and work.  That could be 
just another forum in the beginning.