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.

On 2014-04-26 11:31, 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.

I don't think it's worth adding a completely new keyword for this feature.

Even though many here will hate it I'll say it anyway, yet another feature that could be implemented with AST macros. There's even an example for just C++ namespaces [1].

[1] http://wiki.dlang.org/DIP50#C.2B.2B_Namespaces_.28issue_7961.29

-- 
/Jacob Carlborg

Walter Bright:

> 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.

In understand that in some cases it could be important to interface C++ code with D.

But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++.

Bye,
bearophile

On Saturday, 26 April 2014 at 09:31:48 UTC, Walter Bright wrote:
> There have been many proposals earlier:
>
>   http://forum.dlang.org/post/lhi1lt$269h$1@digitalmars.com
>

My search found the following proposals:

[1]
extern (C++, namespace = A.B) {}

[2]
pragma(cpp_namespace, "A.B")
extern(C++) void f() {}

[3]
@namespace("A")
{
    @namespace("B") {}
}

[4]
extern (C++) template A()
{
    extern (C++) template B() {}
}

[5]
DIP61 a 'namespace' keyword

Would you be willing to summarize the merits/shortcomings of each of these in your opinion?

Mike

[1] http://forum.dlang.org/post/lhpq51$3st$1@digitalmars.com
[2] https://issues.dlang.org/show_bug.cgi?id=7961#c6
[3] https://github.com/D-Programming-Language/dmd/pull/2767
[4] http://forum.dlang.org/post/lhi1lt$269h$1@digitalmars.com
[5] http://forum.dlang.org/post/ljfue4$11dk$1@digitalmars.com

On Saturday, 26 April 2014 at 10:20:30 UTC, bearophile wrote:
>
> But I prefer an ugly-looking feature that will be used only to call C++ functions in namespaces, and not for general D programming. So you will not see D code that looks like C++.

There is an advantage to keeping the D/C++ identifier namespaces separate, with a dedicated C++ syntax. I also don't mind having uglier C++ call syntax, if that makes it possible to visually determine if an identifier is either C/C++ or D at the call site (cpp_ns::identifier).

Does the proposal resolve namespace conflicts between C++ and D? E.g. "std::" etc?

Am Sat, 26 Apr 2014 02:31:51 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> http://wiki.dlang.org/DIP61
> 
> 
> 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.

As the namespace keyword only makes sense for c++ interfacing code it could make sense to implement this as a compiler-recognized UDA:

Benefits:
  * No new keyword, so absolutely no code breakage for old code
    (namespace is likely used in some parser code as an identifier)
  * @namespace is only available when explicitly importing core.cpp
    which makes sense imho
  * No new syntax / parser changes

The rest of the DIP wouldn't be affected in any way.

---------------------------------
module core.cpp; //core.attribute, or any clever name
struct namespace
{
    string ns;
}
---------------------------------

In user code:
---------------------------------
import core.cpp;

@namespace("N")
{
    int foo(); int bar();
}
---------------------------------

Example:
http://dpaste.dzfl.pl/4d583dac89dc


Another small nitpick:
The DIP does not restrict namespaces to C++ interfacing code.
I think we should avoid having namespaces and modules in D, this will
only confuse new users and lead to bad code. We should at least state
this in the DIP or only allow the namespace keyword in extern(C++)
blocks.

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.

I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code.

On 04/26/2014 11:31 AM, 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.
> ...

I agree.

> As more and more people are attempting to call C++ libraries from D,
> this is getting to be a more and more important issue.

Looks good to me, but I think that the current limited lookup rules for template mixins are not really good enough to accommodate for common usage patterns of namespaces.

I think the following should both just work:

import std.stdio;

mixin template Foo(T){
    T foo(T a){ return a; }
}
mixin Foo!int g;
mixin Foo!string g;

void main(){
    writeln(foo(2));
    writeln(foo("a"));
    writeln(g.foo(2));
    writeln(g.foo("a"));
}

// -----

import std.stdio;

namespace g{
    int foo(int a){ return a; }
}
namespace g{
    string foo(string a){ return a; }
}

void main(){
    writeln(foo(2));
    writeln(foo("a"));
    writeln(g.foo(2));
    writeln(g.foo("a"));
}

Both examples should still work if the two mixins/namespaces occur in (possibly different) imported modules. I think this would be in line with how lookup is generally handled in D. (Note that I am not suggesting to make namespaces extensible, but rather to make them overloadable.) How do you think about this?

"Walter Bright"  wrote in message news:ljfue4$11dk$1@digitalmars.com...

> 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.

So, people didn't like the proposal last time you made the thread, so you made it again?  My objections from the last thread still stand.  Mangling is all we need, just add a pragma or attribute to add mangling and don't tie it to other language elements.

For more details go back and read the old thread. 

Is there some reason why
extern(c++, std::printf);
is rejected?
If the purpose here is to map c++ code and we are only worried about namespaces in the c++ context, why not just make it identical to the c++ declaration?

A pragma to indicate the name mangling scheme since MS and GCC use different algorithms and possibly a block element to say everything under here is in this namespace, may
extern(c++namespace, std) {
extern(c++,printf);
extern(c++,open);
}

I know my examples in real code would be extern(c) but this is just for example purposes.

Having both namespaces and modules available in general D code is needless complexity IMHO.