On 4/27/2014 11:01 PM, Walter Bright wrote:
> On 4/27/2014 7:53 PM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Sunday, 27 April 2014 at 20:53:31 UTC, Walter Bright wrote:
>>> Example of what you mean, please.
>>
>> If the c++ library is "std::" and then later either D or C++ is expanded with a
>> name clash, and the externs are auto generated, e.g. "std.something" appears on
>> both sides, what happens then when you recompile you app?
>
>
> I don't know what you mean. D has an excellent system for resolving names that
> appear in multiple scopes.

What I mean is I need a specific code example of what you're talking about, as I cannot deduce it from your statement.

On Monday, 28 April 2014 at 06:18:01 UTC, Walter Bright wrote:
> What I mean is I need a specific code example of what you're talking about, as I cannot deduce it from your statement.

I assume that the type is structural for the extern so that won't be a problem, but if std:: is extern in library1 and library2 and I also later need a D identifier std.something, will I then have to write:

library1.cppbinding.std.something
library2.std.something

instead of std::something?

On 4/27/2014 11:30 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 28 April 2014 at 06:18:01 UTC, Walter Bright wrote:
>> What I mean is I need a specific code example of what you're talking about, as
>> I cannot deduce it from your statement.
>
> I assume that the type is structural for the extern so that won't be a problem,

I have no idea what a type being "structural for the extern" means.

> but if std:: is extern in library1 and library2 and I also later need a D
> identifier std.something, will I then have to write:
>
> library1.cppbinding.std.something
> library2.std.something
>
> instead of std::something?

1. in D you will never write std::something

2. D can access a function foo without qualification in multiple imports, as long as the overloads do not intersect

3. Otherwise, you'll need to qualify to say which one you meant

4. DIP61 does not change name lookup rules

5. If you have an M::foo defined in one C++ library, and M::foo defined in another C++ library, then your program will fail to link, whether you call those libraries from D or C++ code. D does not fix C++'s One Definition Rule.

On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP61

Quote:

> Unlike C++, namespaces in D will be 'closed' meaning that new declarations cannot be inserted into a namespace after the closing }. C++ Argument Dependent Lookup (aka "Koenig Lookup") will not be supported.

Do I understand it correctly, that if I have namespace members defined in different files, like

// a.cpp
namespace ns { int foo(); }
// b.cpp
namespace ns { int bar(); }

I have the only option to put those in a single D file, like

// c.d
extern (C++, ns) { int foo(); int bar(); }

?

And the only way it's more flexible than the hypothetical extern(C++) module ns; is that you can put several namespaces to a single file?

I think he meant next:

A.d:
void foo();

A.cpp:
namespace A { void foo(); }

And now we has:

exnern(C++, A) void foo();
import A;

void main() {
A.foo(); // which foo will be called ? how to call d version or c++ ?
}

There's no linker problem because D and C++ has different name mangling.

On Monday, 28 April 2014 at 06:47:08 UTC, Walter Bright wrote:
> I have no idea what a type being "structural for the extern" means.

"structural" is the wrong word. I meant that if two D frameworks bind the same c++ library you want the two externs to be interchangable in user code. However if D libraries overlaps the identifier path then you run into namespace issues. So the probability of expanding libraries causing issues increase by conflating D and C++ identifier paths.

> 1. in D you will never write std::something

Which will cause unecessary naming conflicts.

> 2. D can access a function foo without qualification in multiple imports, as long as the overloads do not intersect
>
> 3. Otherwise, you'll need to qualify to say which one you meant

So recompiling with updated libraries may cause failure?

On Monday, 28 April 2014 at 07:45:20 UTC, Temtaime wrote:
> I think he meant next:
>
> A.d:
> void foo();
>
> A.cpp:
> namespace A { void foo(); }
>
> And now we has:
>
> exnern(C++, A) void foo();
> import A;
>
> void main() {
> A.foo(); // which foo will be called ? how to call d version or c++ ?
> }

This is close. Forgive inaccurate syntax, but I see at least these issues that will make namespaces/module-system broken in terms of maintenance:

YEAR 2014:

framework1.d:
extern (C++, std){ void something(); }

framework2.d:
extern (C++,std){void something(); void anything();}

application.d:
import framework1;
import framework2;
… std.something(); // is this ok, because the extern signatures match?

---------

YEAR 2015:

std.d is updated:
void something(){}
void coolstuff(){}

application.d is updated to use the new coolstuff():
import framework1;
import framework2;
import.std();
… std.something(); // namespace encapsulation broken or fail?
… std.coolstuff();


application.d is corrected to (or using some other resolution):
import framework1;
import framework2;
import.std();
… framework2.std.something();
… std.coolstuff();

---

YEAR 2016:

framework2.d is modified:
extern (C++,std){ void anything(); }

application.d is recompiled unmodified:
import framework1;
import framework2;
import.std();
 // fails even though the signature is still in framework1
… framework2.std.something();
… std.coolstuff();


> There's no linker problem because D and C++ has different name mangling.

Right, but I want to be sure that the type-system sees all externs with the same signature as the same type. I also am not sure how the "closing of namespaces" will work if you have multiple frameworks that independently specify their own C++ bindings to the same library.

The sole purpose of namespace/modules is to have clean separation between frameworks and support evolutionary development. I am not convinced that this property is not broken with the proposed change.

To get around this you will have to remove the "closing of namespaces" restriction and add a root "cpp" so that all cpp namespaces get: cpp.std.something() etc…

> This is close. Forgive inaccurate syntax, but I see at least these issues that will make namespaces/module-system broken in terms of maintenance:
>
> YEAR 2014:
>
> framework1.d:
> extern (C++, std){ void something(); }
>
> framework2.d:
> extern (C++,std){void something(); void anything();}
>
> application.d:
> import framework1;
> import framework2;
> … std.something(); // is this ok, because the extern signatures match?

Not ok. This is like having 2 definitions for the same function, linker will not accept that.

-Steve

On Sun, 27 Apr 2014 12:54:51 -0700, Walter Bright wrote:

> http://wiki.dlang.org/DIP61

I really like this.  I think it is clean simple and a better approach then adding the namespace keyword.  Plus when people come to D from C++ they wont misuse namespace.

Since D has awesome module aliasing we don't have to worry to much about module/namespace conflicts. Though it would be interesting to alias the extern directly (if we cant already).  alias lib1 = extern(C++, company.lib1) { .... };

My only concern is when libraries have extension libraries that add to the main libraries namespace.  ie:

big_library_everyone_loves_to_use.c++

namespace biglib {
  namespace core {
    ...
  }

}


small_helper_lib_a_few_people_use.c++

namespace biglib {
  void helper1() ... // I call 50 functions so you dont have to!


  namespace core() { ... } // I add extra special memory handlers
}

With the current DIP you have to combine the d/di files to merge the extern namespaces.  Makes it hard to maintain these as separate libraries.  Specially when your library has a lot of extension libs. Maybe someone can write a cleaver mixin for this problem.


Also is there any plans on dealing with newing c++ memory?  Having to add factories to all of the c++ libs feels a little goofy, but either way this DIP gets us a lot closer to C++/D bliss!

On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer wrote:
> Not ok. This is like having 2 definitions for the same function, linker will not accept that.

No. It is like having 2 matching type declarations. The implementation is defined in the C++ source code and is represented as one C++ object/lib file to the linker. The linker will happily accept that.