On Monday, 30 November 2015 at 17:38:06 UTC, Walter Bright wrote:
> It'd be worthwhile to learn how D's name lookup system works before declaring it lame and insufficient:

Nobody has said anything about lame. The issue is that you don't need to know of "version1" on the C++ side. One purpose is to use the "inline" as a switch, so that you can use macros to turn on and off different library subsets. "inline" is injected in front of namespaces that are to be accessible in the parent, and that injection can be done by a macro.

But on the D side you need to know of "version1" if D does not parse C++ headers. Which is a maintenance burden.

On 11/30/2015 10:51 AM, Ola Fosheim Grøstad wrote:
> On Monday, 30 November 2015 at 17:38:06 UTC, Walter Bright wrote:
>> It'd be worthwhile to learn how D's name lookup system works before declaring
>> it lame and insufficient:
>
> Nobody has said anything about lame. The issue is that you don't need to know of
> "version1" on the C++ side.

Did you look at the example I posted?

> One purpose is to use the "inline" as a switch, so
> that you can use macros to turn on and off different library subsets. "inline"
> is injected in front of namespaces that are to be accessible in the parent, and
> that injection can be done by a macro.
>
> But on the D side you need to know of "version1" if D does not parse C++
> headers. Which is a maintenance burden.

Please examine the example I gave again before assuming how D works.

On Monday, 30 November 2015 at 19:38:53 UTC, Walter Bright wrote:
> On 11/30/2015 10:51 AM, Ola Fosheim Grøstad wrote:
>> On Monday, 30 November 2015 at 17:38:06 UTC, Walter Bright wrote:
>>> It'd be worthwhile to learn how D's name lookup system works before declaring
>>> it lame and insufficient:
>>
>> Nobody has said anything about lame. The issue is that you don't need to know of
>> "version1" on the C++ side.
>
> Did you look at the example I posted?

Yes, the problem I see is:

1. You need to know about "version1" which is an internal namespace on the C++ side, so you cannot just create binding to the documented API, but need to go through the source code just to discover that "version1" exists.

2. If the library internals changes on the C++ side it causes problems for D application code, but not for C++ application code.

3.  In order to keep the D and the C++ side call the same set of APIs (if desired) you also need to know on the D side whether the current C++ configuration has enabled "version1" or "version2" (+ a bunch of other potential variations).

In essence the C++ model isn't friendly to foreign languages. They keep bolting on "neat hacks" to extend the language in nonbreaking "transparent" ways (on the C++ side).

On 11/30/2015 12:47 PM, Ola Fosheim Grøstad wrote:
> [...]

Summary: if the C++ declarations change then the D ones that interface to it have to change, too.

I'd have to say that's a given.

On 30/11/2015 10:42 PM, Manu via Digitalmars-d wrote:
>
> Exactly, the D module system would still be in place. Assuming they
> were in defferent modules, then the D module system would keep them
> out of conflict naturally, with rules identical to the normal D rules.
> I imagined this; C++ namespace is for mangling, D module is for
> scoping. That's not how it seems to be, so my intuition was dead
> wrong, but my weekend's experience has convinced me it would be better
> how I initially intuited. Thing is, we're presenting a C++ API to D,
> so we want to present it in D's terms, that is, the API is distributed
> among D modules in a way that makes sense to a D user. I don't want to
> present the API in C++ terms, and it's not even practical; stuffing
> the entire C++ API into a single D module is crazy. In the cases I'm
> interested in, the C++ API is possibly larger than the entire D
> codebase that's attached to it.
>

You're not the only one who thought it should be that way.

On Monday, 30 November 2015 at 21:42:19 UTC, Walter Bright wrote:
> On 11/30/2015 12:47 PM, Ola Fosheim Grøstad wrote:
>> [...]
>
> Summary: if the C++ declarations change then the D ones that interface to it have to change, too.
>
> I'd have to say that's a given.

It might be a given, but as pure C++11 libraries become more common people will need a way to deal with inlined namespaces in a way that isn't annoying. And if the changes does not show up in the mangling, then it won't be caught at link-time either. We'll see...