On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP61
>
> Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces.
>
> There have been many proposals earlier:
>
>   http://forum.dlang.org/post/lhi1lt$269h$1@digitalmars.com
>
> but it seems to me that the simplest, most straightforward approach would be better.
>
> As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue.

BTW, can't we just handle this automatically in a tool like DStep, with the help of pragma(mangle).

--
/Jacob Carlborg

On 4/26/14, 12:27 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:ljgt9v$1psm$1@digitalmars.com...
>
>> Having a pragma to just add mangling doesn't deal with problems like:
>>
>>      namespace N { int foo(); }
>>      namespace M { int foo(); }
>>
>>      foo();  // how to specify which one gets called?
>>
>> I.e. only addressing name mangling does not scale. Need actual scopes,
>> too.
>
> We already have a feature to manage conflicts and organisation in D code
> - modules!  There is no need to add namespaces to do that, and if that's
> really what you want it belongs in a completely different discussion.
>
> The thing we can't (easily) do is mangle C++ namespaces, so a feature
> that only affects mangling is perfect.
>
> i.e. We don't need namespaces in D, because modules cover that.  We only
> need namespace mangling.

Yah, that's why something along the lines of

extern(C++) module facebook.folly;

comes to mind. Following such a module declaration, stuff inside of it is considered inside C++ namespace facebook::folly.

The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file.


Andrei

On 4/26/2014 12:27 PM, Daniel Murphy wrote:
> We already have a feature to manage conflicts and organisation in D code -
> modules!

True. But what D doesn't have is a global namespace. I don't propose one for D, but C++ symbols may appear in the C++ global namespace, or in a C++ namespace. So using D modules to represent C++ namespaces has a problem.

On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
> BTW, can't we just handle this automatically in a tool like DStep, with the help
> of pragma(mangle).

Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ?

On 2014-04-26 09:31:51 +0000, Walter Bright <newshound2@digitalmars.com> said:

> http://wiki.dlang.org/DIP61
> 
> Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't match. Need a simple and straightforward method of indicating namespaces.
> ...
> As more and more people are attempting to call C++ libraries from D, this is getting to be a more and more important issue.

My opinion is that one shouldn't use namespaces in D.

But I do like this namespace concept. It sends the following message: you're welcome to use a namespace if you like -- it'll work -- but 99% of the time it'll only be some decoration in your source code that users of your API can ignore at will because everything is still available at module scope. (The 1% is when there is a name clash.) I think it's a practical thing to do to avoid fake namespace substitutes in D (look at std.datetime.Clock), even if it's a little dirty.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Saturday, 26 April 2014 at 20:07:25 UTC, Andrei Alexandrescu wrote:
>
> Yah, that's why something along the lines of
>
> extern(C++) module facebook.folly;
>
> comes to mind. Following such a module declaration, stuff inside of it is considered inside C++ namespace facebook::folly.
>
> The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file.
>
>
> Andrei

I would argue that this restriction is a benefit not a disadvantage, one would anyway likely use a tool such as DSTEP to create the bindings.

I suppose the greatest benefit would be for people which doesn't use IDE:s, but also compilation time could benefit.

On 2014-04-26 19:13:52 +0000, Walter Bright <newshound2@digitalmars.com> said:

> I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces.

I'd argue that templates aren't the difficult part. Having struct/class semantics ABI-compatible with C++ is the hard part (constructors, destructors, exceptions). Once you have that, the difference between vector_of_int and vector<int> just becomes mangling. Same thing for template functions.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 04/26/2014 08:13 PM, Walter Bright wrote:
>>
>> private mixin template Foo(){
>>      // declarations
>> }
>> mixin Foo foo;
>> ... I guess namespaces will occur in pure D code as
>> sparsely as the above construction, because they are not particularly
>> useful.
>
> Yeah, template mixins turned out to be a solution looking for a problem.

I was actually referring to the exact pattern above. I.e. a parameter-less mixin template that is mixed in immediately exactly one time for the named scope alone. :)

On Saturday, 26 April 2014 at 18:52:41 UTC, Walter Bright wrote:
> On 4/26/2014 11:30 AM, Dicebot wrote:
>> Compromise - consider namespace definition from extern(C++) during name
>> resolution. But still keep actual feature tied to "extern(C++)" to keep its use
>> case clear.
>
> I mentioned something similar in a previous reply to you. Hope that means we can reach a consensus.

Well this corrected version shifts my negative attitude to just "I don't like it" from "I tremble in despair reading it" :) In that sense, it is a breakthrough!

I like Andrei's proposal much-much more though. There needs to be a good tool to interface to C++ namespaces, no doubt. But it should not impact pure D code and it does not need to follow exact C++ code style. Forcing module separation sounds awesome and can be trivially done by binding generator, i.e. dstep.

On Saturday, 26 April 2014 at 20:17:45 UTC, Walter Bright wrote:
> On 4/26/2014 1:06 PM, Jacob Carlborg wrote:
>> BTW, can't we just handle this automatically in a tool like DStep, with the help
>> of pragma(mangle).
>
> Just setting the name mangling is not enough. There's also the issue of how does one refer to A.B.foo() rather than C.D.foo() ?

By putting first foo in A/B.d and second foo in C/D.d