www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - extern(C++, ns) is wrong

reply Manu <turkeyman gmail.com> writes:
file1.d
---------
module bliz.ecs.component_access;
import bliz.ecs.table;
import bliz.ecs.types;
extern(C++, bliz):
// things...

Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): Error:
namespace `bliz.ecs.component_access.bliz` conflicts with import
`bliz.ecs.component_access.bliz` at
project\ecs\include\d2\bliz\ecs\component_access.d(3)

file2.d
---------
module bliz.ecs.table;
import bliz.ecs.types;
extern(C++, bliz):
// things...

Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: namespace
`bliz.ecs.table.bliz` conflicts with import `bliz.ecs.table.bliz` at
project\ecs\include\d2\bliz\ecs\table.d(5)


Oh yeah, I forgot, root namespace in D can not be the same as the C++
namespace... common sense would dictate that they be the same thing,
but that's the exact thing that they can not be.


Walter: This is not sustainable!
Please add no-scope string namespace.
I have no option left available besides literally begging you. Please
put an end to this madness. It can live peacefully beside your
preferred design with the scopes. We can both have our cake.

The design is a critical failure; everything you write leads to
problems in the simplest forms. It's a constant ongoing hurdle, and I
have to contort my code to undo a thing that should never have been
there. It's truly embarrassing. I can't show this to people.

***I can not present my work to stakeholders with a straight face***

I don't know what to do other than fork the compiler and add it
locally, and then we'd be stuck on a dialect, and that would be truly
terrible!

Andrei, please convince Walter to fix this... please.
I beg you both. Just fix it...
There was community consensus in the last uber-thread on the matter.
Sep 04 2018
next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 4 September 2018 at 22:33:34 UTC, Manu wrote:
 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): 
 Error: namespace `bliz.ecs.component_access.bliz` conflicts 
 with import `bliz.ecs.component_access.bliz` at 
 project\ecs\include\d2\bliz\ecs\component_access.d(3)
The obvious workaround is to wrap the entire C++ library in one file, right? Nothing could possibly be suboptimal about that. Just shove four thousand class definitions in there, it'll be fine.
Sep 04 2018
parent Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 16:00, Neia Neutuladh via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 4 September 2018 at 22:33:34 UTC, Manu wrote:
 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7):
 Error: namespace `bliz.ecs.component_access.bliz` conflicts
 with import `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)
The obvious workaround is to wrap the entire C++ library in one file, right? Nothing could possibly be suboptimal about that. Just shove four thousand class definitions in there, it'll be fine.
Even that still wouldn't solve this problem where the root namespace can't be the same as the C++ namespace... which is the common-sense choice for the root namespace >_< I need to think up pointlessly different names for all the C++ package names to call the packages in D.
Sep 04 2018
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...
 
 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)
 
 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...
 
 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: namespace
 `bliz.ecs.table.bliz` conflicts with import `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
Sep 04 2018
next sibling parent reply tide <tide tide.tide> writes:
On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright wrote:
 On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...
 
 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): 
 Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with 
 import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)
 
 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...
 
 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: 
 namespace
 `bliz.ecs.table.bliz` conflicts with import 
 `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
Sep 04 2018
parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright wrote:
 On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7):
 Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with
 import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)

 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error:
 namespace
 `bliz.ecs.table.bliz` conflicts with import
 `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 dmd ns/bar.d ns/baz.d
Sep 04 2018
next sibling parent reply tide <tide tide.tide> writes:
On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright 
 wrote:
 On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: 
 project\ecs\include\d2\bliz\ecs\component_access.d(7):
 Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with
 import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)

 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error:
 namespace
 `bliz.ecs.table.bliz` conflicts with import
 `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 dmd ns/bar.d ns/baz.d
Judging by the name of the modules are you working on an Entity Component System for D :o ?
Sep 04 2018
parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 17:50, tide via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright
 wrote:
 On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error:
 project\ecs\include\d2\bliz\ecs\component_access.d(7):
 Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with
 import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)

 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error:
 namespace
 `bliz.ecs.table.bliz` conflicts with import
 `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 dmd ns/bar.d ns/baz.d
Judging by the name of the modules are you working on an Entity Component System for D :o ?
Well, I'm clearly trying to call C++ code >_<
Sep 04 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 5 September 2018 at 01:20:26 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:50, tide via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 [...]
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 [...]
Judging by the name of the modules are you working on an Entity Component System for D :o ?
Well, I'm clearly trying to call C++ code >_<
I suggest you privately email Walter the exact code files you're writing, with the exact reasons you think his workarounds are too onerous. These piecemeal forum posts are going nowhere.
Sep 04 2018
parent Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 22:05, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 5 September 2018 at 01:20:26 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:50, tide via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 [...]
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 [...]
Judging by the name of the modules are you working on an Entity Component System for D :o ?
Well, I'm clearly trying to call C++ code >_<
I suggest you privately email Walter the exact code files you're writing, with the exact reasons you think his workarounds are too onerous. These piecemeal forum posts are going nowhere.
Workaround: "Naming the binding the same name as the library is incompatible with binding to a library. You need to rename your binding to something other than the name of the library; perhaps you should append 'D', that sounds really pro." That's just not acceptable.
Sep 04 2018
prev sibling parent evilrat <evilrat666 gmail.com> writes:
On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
 That's all you need really, any symbol you add will cause the 
 error.

 extern(C++, bliz):

 created a symbol "bliz", you can't import a package from 
 "bliz" cause then there's a symbol clash. I thought you 
 implemented extern(C++) ...
And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d ------------- module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d ------------- module ns.baz; import ns.bar; extern(C++, ns):
 dmd ns/bar.d ns/baz.d
I just found this little hack for such situations. It seems like a combined effect of mixin template and normal mixin that seems to work by abusing the creation of temporary module for each instantiation. The obvious downside is mixin/CTFE being memory hungry and compilation times increase. Also not sure what happens when there is name clashes due to multiple symbols imported from multiple modules. Tested with DMD 2.082 -m32mscoff on Windows. file1.d ``` mixin template a01() { mixin(` extern(C++, namespaceone) public void fun (); `); } mixin a01; mixin template a02() { mixin(` extern(C++, namespaceone) public void otherfun (); `); } mixin a02; // the rest .... ``` file2.d ``` mixin template a03() { mixin(` extern(C++, namespaceone) public void yetanotherfun (); `); } mixin a03; // ... ```
Oct 10 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 16:35, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/4/2018 3:33 PM, Manu wrote:
 file1.d
 ---------
 module bliz.ecs.component_access;
 import bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): Error:
 namespace `bliz.ecs.component_access.bliz` conflicts with import
 `bliz.ecs.component_access.bliz` at
 project\ecs\include\d2\bliz\ecs\component_access.d(3)

 file2.d
 ---------
 module bliz.ecs.table;
 import bliz.ecs.types;
 extern(C++, bliz):
 // things...

 Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: namespace
 `bliz.ecs.table.bliz` conflicts with import `bliz.ecs.table.bliz` at
 project\ecs\include\d2\bliz\ecs\table.d(5)
I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted.
I'm not asking for help. I know painfully well all the workarounds required to make this stuff work. I'm just showing one case that you tend to be confronted with immediately, which is that if you import a module, and then open a namespace with the same name as the root namespace of a module you imported, that is an error condition; the namespace conflicts with the root namespace of the import.
Sep 04 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2018 5:31 PM, Manu wrote:
 I'm just showing one case that you tend to be confronted with
 immediately, which is that if you import a module, and then open a
 namespace with the same name as the root namespace of a module you
 imported, that is an error condition; the namespace conflicts with the
 root namespace of the import.
I have 30 years of experience doing tech support. I'm not going to guess what the problem is, or try to reconstruct an example from a handwavy description. Been there, done that, far too many times. It just wastes my time and will only frustrate you because I'll solve a different problem.
Sep 04 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Wednesday, 5 September 2018 at 04:39:14 UTC, Walter Bright 
wrote:
 On 9/4/2018 5:31 PM, Manu wrote:
 I'm just showing one case that you tend to be confronted with
 immediately, which is that if you import a module, and then 
 open a
 namespace with the same name as the root namespace of a module 
 you
 imported, that is an error condition; the namespace conflicts 
 with the
 root namespace of the import.
I have 30 years of experience doing tech support. I'm not going to guess what the problem is, or try to reconstruct an example from a handwavy description. Been there, done that, far too many times. It just wastes my time and will only frustrate you because I'll solve a different problem.
The problem has already been described clearly and doesn't really need to be shown.
Sep 04 2018
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/4/2018 5:31 PM, Manu wrote:
 I'm just showing one case that you tend to be confronted with
 immediately, which is that if you import a module, and then open a
 namespace with the same name as the root namespace of a module you
 imported, that is an error condition; the namespace conflicts with the
 root namespace of the import.
I have 30 years of experience doing tech support. I'm not going to guess what the problem is, or try to reconstruct an example from a handwavy description. Been there, done that, far too many times. It just wastes my time and will only frustrate you because I'll solve a different problem.
A hand-wavy description? You recall that last uber-thread right? I can't add anything to that, and I'm not trying to... I'm just, literally, begging you to fix this. I'm serious, you can have your cake, and potentially, I could have my cake too, and everybody would be happy... nobody would be sad.
Sep 04 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2018 10:16 PM, Manu wrote:
 I'm serious, you can have your cake, and potentially, I could have my
 cake too, and everybody would be happy... nobody would be sad.
If it is the same, I provided solutions in those threads. The incomplete example code did not make use of them. I don't know why you have "no option" left.
Sep 05 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 5, 2018 2:30:25 AM MDT Walter Bright via 
Digitalmars-d wrote:
 On 9/4/2018 10:16 PM, Manu wrote:
 I'm serious, you can have your cake, and potentially, I could have my
 cake too, and everybody would be happy... nobody would be sad.
If it is the same, I provided solutions in those threads. The incomplete example code did not make use of them. I don't know why you have "no option" left.
If I understand correctly, what it basically comes down to is that Manu finds all of the workarounds that you've suggested to be so annoying as to be intolerable. And after running into some of the same problems yet again, he felt the need to complain about it again and beg you to change your mind, since he feels that he has no idea how to convince you. I get the impression that he thinks that his proposed solution is so obviously better that he doesn't understand why you don't see that it's better, but I don't know. Either way, I think that we all know that it can be very difficult to convince you of something (though that's true of many of us around here). :)
From what I understand of the situation, I'm inclined to agree with Manu's
position on this topic, but I thought that it was clear from the previous discussion that if there were any chance of anything changing, we were going to need a DIP. Based on everything that's been said thus far, I question that that stands much chance of convincing you, but I do think that we need a clear definition of the proposed solution so that we can avoid talking passed each other, which seemed to be happening at least some of the time in the recent thread. Either way, unless someone can come up with an example of the problem or argument about it that somehow convinces you when the previous examples and arguments didn't, I'm not sure that there's much point in arguing about it without at least having a clear DIP on the topic. - Jonathan M Davis
Sep 05 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/09/2018 9:35 PM, Jonathan M Davis wrote:
 On Wednesday, September 5, 2018 2:30:25 AM MDT Walter Bright via
 Digitalmars-d wrote:
 On 9/4/2018 10:16 PM, Manu wrote:
 I'm serious, you can have your cake, and potentially, I could have my
 cake too, and everybody would be happy... nobody would be sad.
If it is the same, I provided solutions in those threads. The incomplete example code did not make use of them. I don't know why you have "no option" left.
If I understand correctly, what it basically comes down to is that Manu finds all of the workarounds that you've suggested to be so annoying as to be intolerable. And after running into some of the same problems yet again, he felt the need to complain about it again and beg you to change your mind, since he feels that he has no idea how to convince you. I get the impression that he thinks that his proposed solution is so obviously better that he doesn't understand why you don't see that it's better, but I don't know. Either way, I think that we all know that it can be very difficult to convince you of something (though that's true of many of us around here). :)
From what I understand of the situation, I'm inclined to agree with Manu's
position on this topic, but I thought that it was clear from the previous discussion that if there were any chance of anything changing, we were going to need a DIP. Based on everything that's been said thus far, I question that that stands much chance of convincing you, but I do think that we need a clear definition of the proposed solution so that we can avoid talking passed each other, which seemed to be happening at least some of the time in the recent thread. Either way, unless someone can come up with an example of the problem or argument about it that somehow convinces you when the previous examples and arguments didn't, I'm not sure that there's much point in arguing about it without at least having a clear DIP on the topic. - Jonathan M Davis
+1 My interpretation is very similar, only difference is that Manu is asking for is removal of some artificial restrictions put in place to prevent possible problems that probably won't appear in D. I agree with the solution you have provided to move forward. I think we're done arguing, Walter just doesn't seem to want to accept Manu's use case as-is.
Sep 05 2018
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 5 September 2018 at 08:30:25 UTC, Walter Bright 
wrote:
 On 9/4/2018 10:16 PM, Manu wrote:
 I'm serious, you can have your cake, and potentially, I could 
 have my
 cake too, and everybody would be happy... nobody would be sad.
If it is the same,
It is
 I provided solutions in those threads. The incomplete example 
 code did not make use of them.
Those "solutions" do not satisfactorily solve the problem, hence:
I have to contort my code to undo a thing that should never have 
been there. It's truly >embarrassing. I can't show this to 
people.

***I can not present my work to stakeholders with a straight 
face***
I don't think I could either.
 I don't know why you have "no option" left.
There is one: add it to LDC, which will accept it, see https://github.com/ldc-developers/ldc/issues/2800#issuecomment-410817126 but this is a language feature we (LDC) would rather not have an upstream diff for. This is a prime example of an industry blocker if ever there was. Yes there has been a lot of talking past each other, but surely you understand _what_ Manu is wanting even if you seem to think that your workarounds (which you called solutions) are sufficient. It is backwards compatible and solves a clear need, I don't see why this is such a contentious issue.
Sep 05 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 5, 2018 7:03:26 AM MDT Nicholas Wilson via 
Digitalmars-d wrote:
 This is a prime example of an industry blocker if ever there was.
 Yes there has been a lot of talking past each other, but surely
 you understand _what_  Manu is wanting even if you seem to think
 that your workarounds (which you called solutions) are
 sufficient. It is backwards compatible and solves a clear need, I
 don't see why this is such a contentious issue.
Based on everything Walter said in the previous thread, it honestly seems to me to be primarily like he just can't give up on the idea that D has to worry about modeling C++ namespaces. Pretty much all of the extra complications that come from the current approach stem from insisting on modeling namespaces in D instead of just treating the namespace as part of the information that you give to the compiler to indicate what the symbol in D is supposed to correspond to in C++ when the compiler goes to mangle it. What Walter did makes perfect sense if you assume that D needs to care about namespaces when using the C++ symbol in D, but the conclusion of the rest of us when looking at the problem has been that D really doesn't need to care about the namespaces beyond mangling, because D modules already solve the problem. In actuality, there's no more need to worry about a C++ symbol's namespace when using it in D than there is to have to care about which header file a C symbol lives in when you use it in D. The module you put it in will likely relate to the header file that it comes from, and in the case of a C++ symbol, it may even relate to the namespace that it's in in C++, but that's just a matter of sanely organizing your bindings in D so that folks using the code will have an easy time finding the symbols if they know where they live in C/C++. It's not required for actually differentiating the symbols when using them in D. The modules already take care of that quite well. And if you really have a situation where multiple namespaces with the same symbol name live in a C++ header, and you want to put them in the same module in D, it should be trivial to stick them in structs, classes, or templates to namespace them like folks already sometimes do with D code when they want to emulate namespaces in D. Or if we left the current implementation in addition to what Manu wants, then the current approach could be used in those cases. So, the primary situation that Walter brought up with using the module system to differentiate symbols rather than having the compiler emulate the namespace like it currently does should be very solvable with what Manu wants, whereas every issue that Manu and Atila brought up required jumping through hoops in order to get it working with the current solution, and it frequently ends up not only being much harder to implement, but it's less user-friendly for the programmers using the bindings. So, if you can accept the idea that there really is no need to emulate C++ namespaces in D - even if you want to be able to stick multiple namespaces in the same module - then I really don't see any reason to prefer the current approach to extern(C++, "namespace") like Manu wants. But for whatever reason, Walter just doesn't seem to accept the idea that it's unnecessary to emulate namespaces in D in order to link to them, and he thinks that all of the hoops that it causes you to jump through are worse than the extra hoops that you would have to jump through to get multiple namespaces in the same file if extern(C++, namespace) weren't a thing. I can understand that from the standpoint that extern(C++, namespace) has already been implemented, whereas extern(C++, "namespace") has not been. So, even if we were to then have both instead of replacing one with the other, there's definitely work involved. However, I fail to understand why extern(C++, namespace) is superior from a technical perspective. Rather, it clearly has some serious drawbacks in comparison to extern(C++, "namespace"). But be it because of the effort involved with implementing a new solution, or because the current solution was his idea, or because of some other reason, thus far, Walter just doesn't seem to want to come around to the idea that all we need is the mangling, and then we should be able to do everything else we need with what D already provides. Worst case, we might need to make adjustments to make sure that something like static Namespace { extern(C++, "Namespace") static bool freeFunc(int foo); } can compile without expecting freeFunc to be part of a struct. But I'm pretty sure that even if that wouldn't work, a template could be used as the namespace isnead, and we could even choose to leave in extern(C++, Namespace) bool freeFunc(int foo); for the rare case where that makes more sense than simply letting the module system do its job. But regardless, I'm with you and Manu at this point in that I don't understand why extern(C++, "Namespace") isn't a clearly better (and simpler) solution overall. But maybe we'll get lucky and after Walter has thought about it long enough, he'll come around. Either way, per the current process, we would clearly need a DIP even if Walter already agreed. So, the next step is to write a DIP, and hopefully it can be written well enough that it's appropriately convincing unlike everything that has been argued thus far. - Jonathan M Davis
Sep 05 2018
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis 
wrote:

Very well said, thanks.

 Based on everything Walter said in the previous thread, it 
 honestly seems to me to be primarily like he just can't give up 
 on the idea that D has to worry about modeling C++ namespaces.
That is the conclusion I came to as well.
 What Walter did makes perfect sense if you assume that D needs 
 to care about namespaces when using the C++ symbol in D, but 
 the conclusion of the rest of us when looking at the problem 
 has been that D really doesn't need to care about the 
 namespaces beyond mangling, because D modules already solve the 
 problem.
I think this is the key insight, everything else follows from this.
 But regardless, I'm with you and Manu at this point in that I 
 don't understand why extern(C++, "Namespace") isn't a clearly 
 better (and simpler) solution overall. But maybe we'll get 
 lucky and after Walter has thought about it long enough, he'll 
 come around. Either way, per the current process, we would 
 clearly need a DIP even if Walter already agreed. So, the next 
 step is to write a DIP, and hopefully it can be written well 
 enough that it's appropriately convincing unlike everything 
 that has been argued thus far.
Indeed, It is a pity the DIP pipeline is so full. Manu, what timeline do you ideally need this by? and do you have an implementation? Putting it into LDC is probably going to be the fastest given there are 3 high impact DIPs in the queue already + however long takes to get this trough and then implemented.
Sep 05 2018
prev sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis 
wrote:
 On Wednesday, September 5, 2018 7:03:26 AM MDT Nicholas Wilson 
 via Digitalmars-d wrote:
 [...]
Based on everything Walter said in the previous thread, it honestly seems to me to be primarily like he just can't give up on the idea that D has to worry about modeling C++ namespaces. Pretty much all of the extra complications that come from the current approach stem from insisting on modeling namespaces in D instead of just treating the namespace as part of the information that you give to the compiler to indicate what the symbol in D is supposed to correspond to in C++ when the compiler goes to mangle it. [...]
I wholeheartedly agree. C++ namespaces are a C++ language idea that D has discarded in favor of much simpler facilities. Injecting that <expletive-deleted> back into D when linking to C++ is polluting D with needless complexity at odds with that gain in simplicity. The name collision problem with two namespaces containing the same name can be resolved with much simpler facilities. For example, at the point of the extern declaration, the name of the linked entity could be provided as an optional third parameter so that the name in D could be different. I'm sure many other simple schemes could be invented, more consistent with D's approach.
Sep 10 2018
next sibling parent Manu <turkeyman gmail.com> writes:
On Mon, 10 Sep 2018 at 13:40, Carl Sturtivant via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis
 wrote:
 On Wednesday, September 5, 2018 7:03:26 AM MDT Nicholas Wilson
 via Digitalmars-d wrote:
 [...]
Based on everything Walter said in the previous thread, it honestly seems to me to be primarily like he just can't give up on the idea that D has to worry about modeling C++ namespaces. Pretty much all of the extra complications that come from the current approach stem from insisting on modeling namespaces in D instead of just treating the namespace as part of the information that you give to the compiler to indicate what the symbol in D is supposed to correspond to in C++ when the compiler goes to mangle it. [...]
I wholeheartedly agree. C++ namespaces are a C++ language idea that D has discarded in favor of much simpler facilities. Injecting that <expletive-deleted> back into D when linking to C++ is polluting D with needless complexity at odds with that gain in simplicity. The name collision problem with two namespaces containing the same name can be resolved with much simpler facilities. For example, at the point of the extern declaration, the name of the linked entity could be provided as an optional third parameter so that the name in D could be different. I'm sure many other simple schemes could be invented, more consistent with D's approach.
This is a problem that doesn't need a solution. Just use modules; this is precisely what they're for. I, for one, have faith in the module design.
Sep 10 2018
prev sibling next sibling parent reply Danni Coy <danni.coy gmail.com> writes:
So my understanding is that the main issue with extern(C++,"ns") is
functions that have different C++ name-spaces overriding each other in
unexpected ways.
How feasible is to simply disallow functions/variables/objects/... with the
same name but a different "ns" being in the same module?
Sep 11 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Wednesday, 12 September 2018 at 03:59:30 UTC, Danni Coy wrote:
 So my understanding is that the main issue with 
 extern(C++,"ns") is
 functions that have different C++ name-spaces overriding each 
 other in
 unexpected ways.
 How feasible is to simply disallow 
 functions/variables/objects/... with the
 same name but a different "ns" being in the same module?
Very. The compiler would do it automatically because they would cause name collisions.
Sep 11 2018
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 So my understanding is that the main issue with extern(C++,"ns") is functions
that have different C++ name-spaces overriding each other in unexpected ways.
 How feasible is to simply disallow functions/variables/objects/... with the
same name but a different "ns" being in the same module?
That's natural behaviour. You can't declare the same symbol twice in the same scope.
Sep 12 2018
prev sibling parent Danni Coy <danni.coy gmail.com> writes:
On Thu, Sep 13, 2018, 07:06 Manu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 So my understanding is that the main issue with extern(C++,"ns") is
functions that have different C++ name-spaces overriding each other in unexpected ways.
 How feasible is to simply disallow functions/variables/objects/... with
the same name but a different "ns" being in the same module? That's natural behaviour. You can't declare the same symbol twice in the same scope.
Sorry I meant in the instance where a function has the same name but a different signature and the wrong function might be called because of implicit promotion of a variable. How feasible is it to have the compiler simply disallow this and force you to put such functions in different d modules?
Sep 12 2018
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/4/2018 5:31 PM, Manu wrote:
 I'm just showing one case that you tend to be confronted with
 immediately, which is that if you import a module, and then open a
 namespace with the same name as the root namespace of a module you
 imported, that is an error condition; the namespace conflicts with the
 root namespace of the import.
I have 30 years of experience doing tech support. I'm not going to guess what the problem is, or try to reconstruct an example from a handwavy description. Been there, done that, far too many times. It just wastes my time and will only frustrate you because I'll solve a different problem.
"A handwavy description"! What do you mean? I started the email with the code... if you compiled it you would have reproduced those error messages. Yes the line numbers would have been different line numbers, because I deleted all the other lines, but the code I pasted reproduces the errors precisely. And you know that anyway. You don't need to compile the code to understand the error, we've been over it countless times for years now.
Sep 04 2018
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 5 September 2018 at 05:32:43 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 [...]
"A handwavy description"! What do you mean? I started the email with the code... if you compiled it you would have reproduced those error messages. Yes the line numbers would have been different line numbers, because I deleted all the other lines, but the code I pasted reproduces the errors precisely. And you know that anyway. You don't need to compile the code to understand the error, we've been over it countless times for years now.
what about run.dlang.org?
Sep 05 2018
parent bauss <jj_1337 live.dk> writes:
On Wednesday, 5 September 2018 at 07:22:50 UTC, Paolo Invernizzi 
wrote:
 On Wednesday, 5 September 2018 at 05:32:43 UTC, Manu wrote:
 On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 [...]
"A handwavy description"! What do you mean? I started the email with the code... if you compiled it you would have reproduced those error messages. Yes the line numbers would have been different line numbers, because I deleted all the other lines, but the code I pasted reproduces the errors precisely. And you know that anyway. You don't need to compile the code to understand the error, we've been over it countless times for years now.
what about run.dlang.org?
I don't think you can link against C++ code there.
Sep 05 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/4/2018 10:32 PM, Manu wrote:
 "A handwavy description"!
 What do you mean? I started the email with the code... if you compiled
 it you would have reproduced those error messages.
There are 3 files referenced, but only two are given.
Sep 05 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 11, 2018 9:59:30 PM MDT Danni Coy via Digitalmars-d 
wrote:
 So my understanding is that the main issue with extern(C++,"ns") is
 functions that have different C++ name-spaces overriding each other in
 unexpected ways.
 How feasible is to simply disallow functions/variables/objects/... with
 the same name but a different "ns" being in the same module?
If we had extern(C++, "NS"), then all it would affect would be mangling and all of the normal rules for conflicting symbols would be in force. So, if you tried to put two symbols with the same name but from different namespaces in the same module, you'd get an error just like if they were D functions that conflicted. Disallowing it wouldn't be the problem. The problem would be if you were trying to match the C++ header file and thus have the two namespaces in the same file without a conflict, and that wouldn't work unless you could do something like put the symbol inside a struct or template to effectively namespace it - or if the current extern(C++, NS) mechanism were left in place in addition to adding extern(C++, "NS"). But for the most part, this is a non-issue, because the sane thing to do would be to just put different namespaces in different modules even if they were in the same header file in C++ - maybe pkg.headerfile.namespace instead of pkg.headerfile like you might do if everything in the header file were in the same namespace. It might be more of a problem with something that generated the bindings automatically, but mostly, the issue seems to be that Walter wants to be able to completely follow the C++ header scheme when you create the bindings, whereas most of the rest of us don't really care about being that exact about it if the header file did something like have multiple namespaces with symbols that would conflict if they were in the same namespace. Since the current scheme effectively creates namespaces inside of the module instead of just affecting the name mangling, you can stick as many namespaces in the module as you want without worrying about conflicts, but you then get other fun problems like having to declare everything in the namespace sequentially and having to refer everything in the namespace with the namespace unless you alias it all. So really, the most flexible solution would probably to have extern(C++, "NS") which only affects the mangling and then make sure that it works to do something like struct Namespace { extern(C++, "Namespace") static void foo(int bar); } thereby allowing you to have symbols from multiple namespaces in the same module even if they have conflicting names. In most cases, people would then just do extern(C++, "Namespace") void foo(int bar); and it's nice and simple, whereas if they really wanted to put conflicting symbols in the same module instead of just putting them in separate module like you would with D symbols, they could then explicitly namespace them. But given what we already have in the language, the simplest alternative would be to just add extern(C++, "Namespace") and leave extern(C++, Namespace) so that most code could use extern(C++, "Namespace"), and those rare cases where you really don't want to put conflicting symbols in separate modules, you use the current scheme of extern(C++, Namespace). The main downside is that having both constructs risks being confusing. Really though, there isn't much of a downside to the extern(C++, "Namespace") solution even if it were the only one. - Jonathan M Davis
Sep 11 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 12, 2018 3:06:23 PM MDT Manu via Digitalmars-d 
wrote:
 On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 So my understanding is that the main issue with extern(C++,"ns") is
 functions that have different C++ name-spaces overriding each other in
 unexpected ways. How feasible is to simply disallow
 functions/variables/objects/... with the same name but a different "ns"
 being in the same module?
That's natural behaviour. You can't declare the same symbol twice in the same scope.
And that's really what's so nice about the idea behind extern(C++, "NS"). It's incredibly simple, because it follows _all_ of the normal D semantics. It's just that it then affects how the symbols are mangled so that they link up with the C++ symbols that they're bindings for. So, the whole thing is incredibly easy to reason about. The only downside that I'm aware of is that it makes it harder to put multiple namespaces in the same file, which matters if you're trying to put all of the symbols from a particular header file in a corresponding module. In every other respect, it's simpler - and incredibly easy to reason about. - Jonathan M Davis
Sep 12 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 12, 2018 11:29:42 PM MDT Danni Coy via Digitalmars-d 
wrote:
 On Thu, Sep 13, 2018, 07:06 Manu via Digitalmars-d <

 digitalmars-d puremagic.com> wrote:
 On Tue, 11 Sep 2018 at 20:59, Danni Coy via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 So my understanding is that the main issue with extern(C++,"ns") is
functions that have different C++ name-spaces overriding each other in unexpected ways.
 How feasible is to simply disallow functions/variables/objects/...
 with
the same name but a different "ns" being in the same module? That's natural behaviour. You can't declare the same symbol twice in the same scope.
Sorry I meant in the instance where a function has the same name but a different signature and the wrong function might be called because of implicit promotion of a variable. How feasible is it to have the compiler simply disallow this and force you to put such functions in different d modules?
The entire point of having extern(C++, "NS") would be to make it so that the _only_ thing that it would affect would be the name mangling. Everything else is exactly the same behavior as it would be if you had the same functions as extern(D). It would be up to the programmer to organize them exactly like it is with pure D code. If you think that putting two functions in the same module is too risky, then you can put them in separate modules, but it certainly isn't going to be forced on you unless they actually conflict. The fact that functions are extern(C++) would have no impact on that whatsoever. - Jonathan M Davis
Sep 13 2018
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 The entire point of having extern(C++, "NS") would be to make it so that
 the
 _only_ thing that it would affect would be the name mangling. Everything
 else is exactly the same behavior as it would be if you had the same
 functions as extern(D). It would be up to the programmer to organize them
 exactly like it is with pure D code. If you think that putting two
 functions
 in the same module is too risky, then you can put them in separate modules,
 but it certainly isn't going to be forced on you unless they actually
 conflict. The fact that functions are extern(C++) would have no impact on
 that whatsoever.
Yeah I get all this. It just seems to me that the downsides of extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility. I would like to know how difficult that would be to do and whether that would be more acceptable to Walter than what is being being proposed.
Sep 13 2018
prev sibling next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 13, 2018 5:45:56 AM MDT Danni Coy via Digitalmars-d 
wrote:
 On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <

 digitalmars-d puremagic.com> wrote:
 The entire point of having extern(C++, "NS") would be to make it so that
 the
 _only_ thing that it would affect would be the name mangling. Everything
 else is exactly the same behavior as it would be if you had the same
 functions as extern(D). It would be up to the programmer to organize
 them
 exactly like it is with pure D code. If you think that putting two
 functions
 in the same module is too risky, then you can put them in separate
 modules, but it certainly isn't going to be forced on you unless they
 actually conflict. The fact that functions are extern(C++) would have
 no impact on that whatsoever.
Yeah I get all this. It just seems to me that the downsides of extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility. I would like to know how difficult that would be to do and whether that would be more acceptable to Walter than what is being being proposed.
I don't know what Walter would go for, but trying to do anything special for extern(C++, "NS") symbols pretty much defeats the whole purpose of using extern(C++, "NS") over extern(C++, NS). And the issue that you are trying to find a way to prevent is something that D code in general has to worry about, so I don't think that it makes any sense to try to treat extern(C++) symbols as special to try to fix it. If we have extern(C++, "NS"), then anyone creating C++ bindings will have to worry about conflicts in exactly the same way that they would with D code. You have to do that with extern(C++, NS) too. It's that it's then only with the functions within that namespace. Walter's concerns seem to center around the idea that we somehow need to model C++ namespaces in D, so that's really what needs to be addressed somehow. The D module system gives us everything we need to lay out symbols so that they don't conflict. The only thing that it can't do is allow you to put conflicting symbols in the same module, making it harder to have a 1-to-1 correspondance between D modules and C++ header files in rare cases, but all we need to do to solve that is to either leave in extern(C++, NS) for those cases or to make it so that something like static NS1 { extern(C++, "NS1") static void foo(int bar); } static NS2 { extern(C++, "NS2") static void foo(int bar); } works (which is basically what extern(C++, NS) is doing anyway). But honestly, in most cases, it just makes more sense to split up the symbols between modules, and in the vast majority of cases, you simply don't have multiple namespaces with conflicting symbols in the same header file. - Jonathan M Davis
Sep 13 2018
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, 13 Sep 2018 at 13:01, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 Walter's concerns seem to center around the idea that we somehow need to
 model C++ namespaces in D, so that's really what needs to be addressed
 somehow. The D module system gives us everything we need to lay out symbols
 so that they don't conflict. The only thing that it can't do is allow you to
 put conflicting symbols in the same module, making it harder to have a
 1-to-1 correspondance between D modules and C++ header files in rare cases,
But consider the overwhelmingly common case where C++ namespaces span across many files. You can't distribute extern(C++, ns) across D modules, so D fails to model C++ namespaces regardless, and in the vast majority case. The minority case you point out above is irrelevant by contrast. The current design fails at its primary goal right out of the gate, but we wear a pile of super-anger-inducing baggage in its wake.
Sep 13 2018
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On Thu, 13 Sep 2018 at 04:46, Danni Coy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 The entire point of having extern(C++, "NS") would be to make it so that the
 _only_ thing that it would affect would be the name mangling. Everything
 else is exactly the same behavior as it would be if you had the same
 functions as extern(D). It would be up to the programmer to organize them
 exactly like it is with pure D code. If you think that putting two functions
 in the same module is too risky, then you can put them in separate modules,
 but it certainly isn't going to be forced on you unless they actually
 conflict. The fact that functions are extern(C++) would have no impact on
 that whatsoever.
Yeah I get all this. It just seems to me that the downsides of extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility.
What are the 'downsides' you refer to? And what 'flexibility' is lost? The whole point is to gain flexibility. There's definitely no loss of flexibility on the table here ;)
 I would like to know how difficult that would be to do and whether that would
be more acceptable to Walter than what is being being proposed.
You'll need to elaborate. What is being proposed is the simplest possible, most plainly obvious, let's-not-introduce-unwieldy-edge-cases solution. Walters named scope should be an unrelated and parallel feature if he really wants it.
Sep 13 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Thursday, September 13, 2018 4:43:47 PM MDT Manu via Digitalmars-d wrote:
 On Thu, 13 Sep 2018 at 13:01, Jonathan M Davis via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 Walter's concerns seem to center around the idea that we somehow need to
 model C++ namespaces in D, so that's really what needs to be addressed
 somehow. The D module system gives us everything we need to lay out
 symbols so that they don't conflict. The only thing that it can't do is
 allow you to put conflicting symbols in the same module, making it
 harder to have a 1-to-1 correspondance between D modules and C++ header
 files in rare cases,
But consider the overwhelmingly common case where C++ namespaces span across many files. You can't distribute extern(C++, ns) across D modules, so D fails to model C++ namespaces regardless, and in the vast majority case. The minority case you point out above is irrelevant by contrast. The current design fails at its primary goal right out of the gate, but we wear a pile of super-anger-inducing baggage in its wake.
I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which 1. really clearly explains the semantics (which shouldn't be hard given their simplicity). 2. does an excellent job of explaining the downsides to the current approach, why they're such a big problem, why workarounds for those problems are terrible, and why the proposed approach doesn't have those same problems. 3. and of course, for thoroughness, it needs to explain the downsides to the proposed approach and the likely workarounds, but the issue of trying to put multiple namespaces in a single module when they were in a single header file is the only downside that I'm aware of. How easy it's going to be to put something together that convinces Walter, I don't know, but we clearly need a well-written DIP to stand a chance, and I have no clue what arguments would convince Walter. I don't know what Andrei thinks on the subject, but maybe the trick is to write the DIP so well that Andrei is convinced, and then _he_ convinces Walter. And maybe we'll get lucky, and after Walter mulls over it enough, he'll come around. I don't know. Either way, I don't think that you really need to convince many folks who have actually dealt with extern(C++, NS). At least out of those folks who say anything in the forums, it seems that pretty much anyone (other than Walter) who looks into the issue much pretty quickly comes to the conclusion that the current approach is terrible. It's Walter who is clearly hard to convince. - Jonathan M Davis
Sep 13 2018
parent reply Zot <Zot Zot.Zot> writes:
On Thursday, 13 September 2018 at 23:30:33 UTC, Jonathan M Davis 
wrote:
 On Thursday, September 13, 2018 4:43:47 PM MDT Manu via 
 Digitalmars-d wrote:
 [...]
I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which [...]
As someone who does a lot of c/c++ binding I am 100% in favor of Manu's extern(C++, "ns") I also want to point out that extern should work in mixins (see bug https://issues.dlang.org/show_bug.cgi?id=12575). So probably a good idea to clearify interactions like that in a DIP as well. - Zot
Sep 14 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
 On Thursday, 13 September 2018 at 23:30:33 UTC, Jonathan M 
 Davis wrote:
 On Thursday, September 13, 2018 4:43:47 PM MDT Manu via 
 Digitalmars-d wrote:
 [...]
I'm not disagreeing, but I'm not the person who needs to be convinced. Either way, a DIP needs to be produced which [...]
As someone who does a lot of c/c++ binding I am 100% in favor of Manu's extern(C++, "ns") I also want to point out that extern should work in mixins (see bug https://issues.dlang.org/show_bug.cgi?id=12575). So probably a good idea to clearify interactions like that in a DIP as well. - Zot
I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does. Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link. Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends. Forum chatter won't do it though, we need a DIP.
Sep 14 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
 On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
 [...]
I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does. Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link. Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends. Forum chatter won't do it though, we need a DIP.
Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-things-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md
Sep 14 2018
next sibling parent Manu <turkeyman gmail.com> writes:
On Fri, 14 Sep 2018 at 07:55, 12345swordy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
 On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
 [...]
I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does. Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link. Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends. Forum chatter won't do it though, we need a DIP.
Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-things-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md
I can't wait for a DIP. That's like 12 months turnaround, and I've already lost weeks waiting for some trivial PR's about version identifiers that are still pending... this will take years.
Sep 14 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, September 14, 2018 10:56:45 AM MDT Manu via Digitalmars-d wrote:
 On Fri, 14 Sep 2018 at 07:55, 12345swordy via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 On Friday, 14 September 2018 at 13:10:07 UTC, Atila Neves wrote:
 On Friday, 14 September 2018 at 09:56:52 UTC, Zot wrote:
 [...]
I'm also completely in favour of what Manu is saying. The current situation works for no one. I very much doubt that any D programmer exists that wants what extern(C++) currently does. Yes, C++ namespaces are a mess. Who cares? We have modules. All we want is to be able to link. Walter pointed out workarounds, but: they're solutions to a problem that shouldn't exist; are ugly as sin; aren't even sufficient for manually writing bindings in the way the author intends. Forum chatter won't do it though, we need a DIP.
Someone is already on it. https://github.com/look-at-me/DIPs/blob/please-for-the-love-of-all-thing s-good-and-holy-fix-cpp-mangling-please-ok-sorry/DIPs/DIPxCPP.md
I can't wait for a DIP. That's like 12 months turnaround, and I've already lost weeks waiting for some trivial PR's about version identifiers that are still pending... this will take years.
Per the current procedure, it pretty much has to be done via a DIP. It might be possible for it to be fast-tracked, but without Walter and/or Andrei being behind it from the get-go, the chances of that happening aren't good. Really, the only way that this could go quickly would be if Walter and/or Andrei were somehow convinced that extern(C++, NS) was completely broken and that it was critical that it be fixed ASAP. And clearly, Walter is going to be very hard to convince (though maybe we'll get lucky and Andrei will be easy to convince - I have no clue what his position on the issue is). The only real leverage here is likely that they think that C++ integration is important. However, as long as Walter thinks that what we have should work just fine, he's not about to rush to change it. Regardless, given Walter's position on the situation, we pretty much have to have a DIP if nothing else so that we have a clear, well-written document to present to him. Arguing about it in the newsgroup clearly isn't getting us anywhere. After a solid DIP is written, then _maybe_ we could find a way to expedite things, but I think that he's already made it pretty clear that if we want any chance of change, we need a DIP. And while the DIP process might be annoyingly slow, if we don't get a DIP in the queue, I think that it's pretty clear that nothing will change unless Walter or Andrei does something significant with extern(C++, NS) and gets really annoyed at how bad it is (which seems to be how Andrei usually gets fired up on fixing something that other people had been insisting needed to be changed, but he'd thought was fine). - Jonathan M Davis
Sep 14 2018
prev sibling next sibling parent Danni Coy <danni.coy gmail.com> writes:
On Fri, Sep 14, 2018, 08:47 Manu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Thu, 13 Sep 2018 at 04:46, Danni Coy via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <
digitalmars-d puremagic.com> wrote:
 The entire point of having extern(C++, "NS") would be to make it so
that the
 _only_ thing that it would affect would be the name mangling. Everything
 else is exactly the same behavior as it would be if you had the same
 functions as extern(D). It would be up to the programmer to organize
them
 exactly like it is with pure D code. If you think that putting two
functions
 in the same module is too risky, then you can put them in separate
modules,
 but it certainly isn't going to be forced on you unless they actually
 conflict. The fact that functions are extern(C++) would have no impact
on
 that whatsoever.
Yeah I get all this. It just seems to me that the downsides of
extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility. What are the 'downsides' you refer to? And what 'flexibility' is lost? The whole point is to gain flexibility. There's definitely no loss of flexibility on the table here ;)
 I would like to know how difficult that would be to do and whether that
would be more acceptable to Walter than what is being being proposed. You'll need to elaborate. What is being proposed is the simplest possible, most plainly obvious, let's-not-introduce-unwieldy-edge-cases solution. Walters named scope should be an unrelated and parallel feature if he really wants it.
You are suggesting extern(c++,"ns") be a parallel feature to extern(c++,ns). I am asking how difficult technically would it be to have your syntax replace Walters but have the compiler check for the situations where a function from one C++ namespace might shadow one in a different namespace and emit either a warning or an error. Honestly I just want to know if going that path will have more or less friction from Walter.

Sep 14 2018
prev sibling parent reply Danni Coy <danni.coy gmail.com> writes:
On Fri, Sep 14, 2018, 06:01 Jonathan M Davis via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On Thursday, September 13, 2018 5:45:56 AM MDT Danni Coy via Digitalmars-d
 wrote:
 On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d <

 digitalmars-d puremagic.com> wrote:
 The entire point of having extern(C++, "NS") would be to make it so
that
 the
 _only_ thing that it would affect would be the name mangling.
Everything
 else is exactly the same behavior as it would be if you had the same
 functions as extern(D). It would be up to the programmer to organize
 them
 exactly like it is with pure D code. If you think that putting two
 functions
 in the same module is too risky, then you can put them in separate
 modules, but it certainly isn't going to be forced on you unless they
 actually conflict. The fact that functions are extern(C++) would have
 no impact on that whatsoever.
Yeah I get all this. It just seems to me that the downsides of extern(C++,"ns") from Walter's point of view could be handled by the compiler at the cost of a bit of flexibility. I would like to know how difficult that would be to do and whether that would be more acceptable to Walter than what is being being proposed.
I don't know what Walter would go for, but trying to do anything special for extern(C++, "NS") symbols pretty much defeats the whole purpose of using extern(C++, "NS") over extern(C++, NS). And the issue that you are trying to find a way to prevent is something that D code in general has to worry about, so I don't think that it makes any sense to try to treat extern(C++) symbols as special to try to fix it. If we have extern(C++, "NS"), then anyone creating C++ bindings will have to worry about conflicts in exactly the same way that they would with D code. You have to do that with extern(C++, NS) too. It's that it's then only with the functions within that namespace. Walter's concerns seem to center around the idea that we somehow need to model C++ namespaces in D, so that's really what needs to be addressed somehow. The D module system gives us everything we need to lay out symbols so that they don't conflict. The only thing that it can't do is allow you to put conflicting symbols in the same module, making it harder to have a 1-to-1 correspondance between D modules and C++ header files in rare cases, but all we need to do to solve that is to either leave in extern(C++, NS) for those cases or to make it so that something like static NS1 { extern(C++, "NS1") static void foo(int bar); } static NS2 { extern(C++, "NS2") static void foo(int bar); } works (which is basically what extern(C++, NS) is doing anyway). But honestly, in most cases, it just makes more sense to split up the symbols between modules, and in the vast majority of cases, you simply don't have multiple namespaces with conflicting symbols in the same header file. - Jonathan M Davis
So extern(C++,"ns") replaces the existing syntax and then improve D's general ability to hand functioning hijacking other functions would be the best solution and Walters modelling of namespaces is fixing the problem in the wrong place?

Sep 14 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Saturday, 15 September 2018 at 00:07:44 UTC, Danni Coy wrote:
 So extern(C++,"ns") replaces the existing syntax
It would be in addition, at least at first. The current syntax might be deprecated.
 and then improve D's general ability to hand functioning 
 hijacking other functions would be the best solution
D already has tools for this.
 and Walters modelling of namespaces is fixing the problem in 
 the wrong place?
The current solution solves the very uncommon problem of having two different namespaces in the same file, containing symbols with the same names (or, if functions, with common overloads), where the person writing the bindings needs to keep a one-to-one correspondence between C++ headers and D files, and they don't want to introduce any meaningless structs or templates. Specifically, Walter wants this to compile: module whatever; extern(C++, foo) void doStuff(); extern(C++, bar) void doStuff(); And he's not too concerned that you might have to use doubly fully qualified names to refer to C++ symbols, like: import core.stdcpp.sstream; import core.stdcpp.vector; core.stdcpp.vector.std.vector v;
Sep 14 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/14/18 6:41 PM, Neia Neutuladh wrote:

 Specifically, Walter wants this to compile:
 
 module whatever;
 extern(C++, foo) void doStuff();
 extern(C++, bar) void doStuff();
 
 And he's not too concerned that you might have to use doubly fully 
 qualified names to refer to C++ symbols, like:
 
 import core.stdcpp.sstream;
 import core.stdcpp.vector;
 core.stdcpp.vector.std.vector v;
This is probably the best explanation of why the current situation sucks. -Steve
Sep 16 2018
parent reply Atila Neves <atila.neves gmail.com> writes:
On Sunday, 16 September 2018 at 17:46:26 UTC, Steven 
Schveighoffer wrote:
 On 9/14/18 6:41 PM, Neia Neutuladh wrote:

 Specifically, Walter wants this to compile:
 
 module whatever;
 extern(C++, foo) void doStuff();
 extern(C++, bar) void doStuff();
 
 And he's not too concerned that you might have to use doubly 
 fully qualified names to refer to C++ symbols, like:
 
 import core.stdcpp.sstream;
 import core.stdcpp.vector;
 core.stdcpp.vector.std.vector v;
This is probably the best explanation of why the current situation sucks. -Steve
Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.
Sep 17 2018
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 16 September 2018 at 17:46:26 UTC, Steven
 Schveighoffer wrote:
 On 9/14/18 6:41 PM, Neia Neutuladh wrote:

 Specifically, Walter wants this to compile:

 module whatever;
 extern(C++, foo) void doStuff();
 extern(C++, bar) void doStuff();

 And he's not too concerned that you might have to use doubly
 fully qualified names to refer to C++ symbols, like:

 import core.stdcpp.sstream;
 import core.stdcpp.vector;
 core.stdcpp.vector.std.vector v;
This is probably the best explanation of why the current situation sucks. -Steve
Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.
https://github.com/dlang/dmd/pull/8667 O_O Thank you Walter for coming to the party!
Sep 18 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/18/2018 5:22 PM, Manu wrote:
 Thank you Walter for coming to the party!
I suppose I should explain this. 1. The PR uses a different syntax, i.e. strings instead of identifiers. This implies it is not creating a scope, and doesn't interfere with the scoping of the existing syntax. The design of the feature is simple and easy to document and understand, and doesn't break anything. 2. Manu and Atila are at the forefront of interfacing with C++. They are both doing massive amounts of work making it work. I'm willing to give a lot of deference to people who know what they are doing and have earned it through their major contributions and longtime membership in our community. 3. The PR for it looks to be a solid piece of work, and even if it turns out otherwise, it's pretty low risk and fixable. Thanks to Manu, Atila and look-at-me.
Sep 19 2018
parent Manu <turkeyman gmail.com> writes:
On Wed, 19 Sep 2018 at 13:15, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 9/18/2018 5:22 PM, Manu wrote:
 Thank you Walter for coming to the party!
I suppose I should explain this. 1. The PR uses a different syntax, i.e. strings instead of identifiers. This implies it is not creating a scope, and doesn't interfere with the scoping of the existing syntax. The design of the feature is simple and easy to document and understand, and doesn't break anything.
Wait up, just to be clear... is this a statement about the PR using strings different than your perception of the conversation surrounding this? This PR implements *exactly* what I was calling for literally the same day that the first patch introducing support was merged however many years ago, and every few months thereafter... I'm just curious to know if this PR was somehow surprising to you. Because if so, it demonstrates a total and colossal failure to communicate the preferred design of this feature ;) It was always desired to be a string from day -1, and the bugzilla issue presented it that way too.
Sep 19 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
 On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 On Sunday, 16 September 2018 at 17:46:26 UTC, Steven

 Schveighoffer wrote:
 On 9/14/18 6:41 PM, Neia Neutuladh wrote:
 Specifically, Walter wants this to compile:

 module whatever;
 extern(C++, foo) void doStuff();
 extern(C++, bar) void doStuff();

 And he's not too concerned that you might have to use doubly
 fully qualified names to refer to C++ symbols, like:

 import core.stdcpp.sstream;
 import core.stdcpp.vector;
 core.stdcpp.vector.std.vector v;
This is probably the best explanation of why the current situation sucks. -Steve
Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.
https://github.com/dlang/dmd/pull/8667 O_O Thank you Walter for coming to the party!
Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around. - Jonathan M Davis
Sep 18 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 19/09/2018 1:49 PM, Jonathan M Davis wrote:
 On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
 On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:
 On Sunday, 16 September 2018 at 17:46:26 UTC, Steven

 Schveighoffer wrote:
 On 9/14/18 6:41 PM, Neia Neutuladh wrote:
 Specifically, Walter wants this to compile:

 module whatever;
 extern(C++, foo) void doStuff();
 extern(C++, bar) void doStuff();

 And he's not too concerned that you might have to use doubly
 fully qualified names to refer to C++ symbols, like:

 import core.stdcpp.sstream;
 import core.stdcpp.vector;
 core.stdcpp.vector.std.vector v;
This is probably the best explanation of why the current situation sucks. -Steve
Agreed. Up until now, I didn't even understand the rationale for why it works the way it does.
https://github.com/dlang/dmd/pull/8667 O_O Thank you Walter for coming to the party!
Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around. - Jonathan M Davis
Indeed, thank you Walter!
Sep 18 2018
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/18/18 9:49 PM, Jonathan M Davis wrote:
 On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d wrote:
 https://github.com/dlang/dmd/pull/8667

 O_O

 Thank you Walter for coming to the party!
Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around.
I think a big part is that the implementation was done. I think there's a big difference between "I don't really love this, but crap, I'll have to implement it all" and "I don't really love this, but the implementation isn't too intrusive, and all I have to do is click the merge button, OK." I sure wish I had the skills to hack dmd, there are so many ideas I'd like to see implemented in the language :) Anyways, great to see this merged! -Steve
Sep 19 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, September 19, 2018 7:26:07 AM MDT Steven Schveighoffer via 
Digitalmars-d wrote:
 On 9/18/18 9:49 PM, Jonathan M Davis wrote:
 On Tuesday, September 18, 2018 6:22:55 PM MDT Manu via Digitalmars-d 
wrote:
 https://github.com/dlang/dmd/pull/8667

 O_O

 Thank you Walter for coming to the party!
Oh, wow. I sure wasn't expecting that. I thought that he'd made it pretty clear that a DIP was needed, and even then, it didn't seem likely that it would be accepted. This is awesome. I guess that he finally came around.
I think a big part is that the implementation was done. I think there's a big difference between "I don't really love this, but crap, I'll have to implement it all" and "I don't really love this, but the implementation isn't too intrusive, and all I have to do is click the merge button, OK." I sure wish I had the skills to hack dmd, there are so many ideas I'd like to see implemented in the language :) Anyways, great to see this merged!
Having an implementation available hasn't always done the trick, but it's certainly easier to try to convince Walter accept something that's already been done than to convince him that he should implement something - which really shouldn't be a surprise. I expect that pretty much all of us are that way. - Jonathan M Davis
Sep 19 2018