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

Manu (39/39) Sep 04 2018 file1.d

Neia Neutuladh (5/9) Sep 04 2018 The obvious workaround is to wrap the entire C++ library in one

Manu (7/16) Sep 04 2018 Even that still wouldn't solve this problem where the root namespace

Walter Bright (4/27) Sep 04 2018 I can't help because the examples are incomplete. There is no line 5 in ...

tide (7/38) Sep 04 2018 That's all you need really, any symbol you add will cause the

Manu (14/54) Sep 04 2018 And yes, the example is actually complete. Again, but I'll simplify

tide (3/63) Sep 04 2018 Judging by the name of the modules are you working on an Entity

Manu (3/71) Sep 04 2018 Well, I'm clearly trying to call C++ code >_<

Joakim (4/33) Sep 04 2018 I suggest you privately email Walter the exact code files you're

Manu (7/41) Sep 04 2018 Workaround: "Naming the binding the same name as the library is

evilrat (36/58) Oct 10 2018 I just found this little hack for such situations. It seems like

Manu (9/36) Sep 04 2018 I'm not asking for help. I know painfully well all the workarounds

Walter Bright (5/10) Sep 04 2018 I have 30 years of experience doing tech support. I'm not going to guess...

bauss (4/18) Sep 04 2018 The problem has already been described clearly and doesn't really
Manu (7/17) Sep 04 2018 A hand-wavy description? You recall that last uber-thread right?

Walter Bright (4/6) Sep 05 2018 If it is the same, I provided solutions in those threads. The incomplete...

Jonathan M Davis (22/29) Sep 05 2018 If I understand correctly, what it basically comes down to is that Manu

rikki cattermole (6/40) Sep 05 2018 +1 My interpretation is very similar, only difference is that Manu is

Nicholas Wilson (13/26) Sep 05 2018 It is

Jonathan M Davis (77/83) Sep 05 2018 Based on everything Walter said in the previous thread, it honestly seem...

Nicholas Wilson (12/30) Sep 05 2018 On Wednesday, 5 September 2018 at 13:53:15 UTC, Jonathan M Davis
Carl Sturtivant (13/26) Sep 10 2018 I wholeheartedly agree. C++ namespaces are a C++ language idea

Manu (5/33) Sep 10 2018 This is a problem that doesn't need a solution. Just use modules; this
Danni Coy (5/5) Sep 11 2018 So my understanding is that the main issue with extern(C++,"ns") is

Nicholas Wilson (3/11) Sep 11 2018 Very. The compiler would do it automatically because they would

Manu (4/6) Sep 12 2018 That's natural behaviour. You can't declare the same symbol twice in
Danni Coy (7/19) Sep 12 2018 Sorry I meant in the instance where a function has the same name but a

Manu (11/21) Sep 04 2018 "A handwavy description"!

Paolo Invernizzi (2/17) Sep 05 2018 what about run.dlang.org?

bauss (3/21) Sep 05 2018 I don't think you can link against C++ code there.

Walter Bright (2/5) Sep 05 2018 There are 3 files referenced, but only two are given.

Jonathan M Davis (55/60) Sep 11 2018 If we had extern(C++, "NS"), then all it would affect would be mangling ...
Jonathan M Davis (12/21) Sep 12 2018 And that's really what's so nice about the idea behind extern(C++, "NS")...
Jonathan M Davis (12/34) Sep 13 2018 The entire point of having extern(C++, "NS") would be to make it so that...
Danni Coy (7/18) Sep 13 2018 Yeah I get all this. It just seems to me that the downsides of
Jonathan M Davis (33/52) Sep 13 2018 I don't know what Walter would go for, but trying to do anything special...
Manu (9/15) Sep 13 2018 But consider the overwhelmingly common case where C++ namespaces span
Manu (10/23) Sep 13 2018 What are the 'downsides' you refer to? And what 'flexibility' is lost?
Jonathan M Davis (27/43) Sep 13 2018 I'm not disagreeing, but I'm not the person who needs to be convinced.

Zot (9/15) Sep 14 2018 As someone who does a lot of c/c++ binding I am 100% in favor of

Atila Neves (11/28) Sep 14 2018 I'm also completely in favour of what Manu is saying. The current

12345swordy (3/15) Sep 14 2018 Someone is already on it.

Manu (6/25) Sep 14 2018 I can't wait for a DIP.
Jonathan M Davis (25/52) Sep 14 2018 Per the current procedure, it pretty much has to be done via a DIP. It m...

Danni Coy (9/43) Sep 14 2018 You are suggesting extern(c++,"ns") be a parallel feature to
Danni Coy (6/66) Sep 14 2018 So extern(C++,"ns") replaces the existing syntax and then improve D's

Neia Neutuladh (19/24) Sep 14 2018 It would be in addition, at least at first. The current syntax

Steven Schveighoffer (3/15) Sep 16 2018 This is probably the best explanation of why the current situation sucks...

Atila Neves (4/20) Sep 17 2018 Agreed. Up until now, I didn't even understand the rationale for

Manu (5/28) Sep 18 2018 https://github.com/dlang/dmd/pull/8667

Walter Bright (13/14) Sep 19 2018 I suppose I should explain this.

Manu (13/20) Sep 19 2018 Wait up, just to be clear... is this a statement about the PR using

Jonathan M Davis (5/34) Sep 18 2018 Oh, wow. I sure wasn't expecting that. I thought that he'd made it prett...

rikki cattermole (2/42) Sep 18 2018 Indeed, thank you Walter!
Steven Schveighoffer (9/19) Sep 19 2018 I think a big part is that the implementation was done. I think there's

Jonathan M Davis (9/29) Sep 19 2018 wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

D Programming

C/C++ Programming

Other

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