Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Sunday, September 8, 2019 12:12:53 PM MDT Exil via Digitalmars-d-learn wrote: > On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis > > wrote: > > On Saturday, September 7, 2019 3:40:58 PM MDT Exil via > > > > Digitalmars-d-learn wrote: > >> On Saturday, 7 September 2019 at

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis wrote: On Saturday, September 7, 2019 3:40:58 PM MDT Exil via Digitalmars-d-learn wrote: On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: > @safe: > @system: > > then @system overrides @safe. Just to add

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Sunday, 8 September 2019 at 09:35:03 UTC, Jonathan M Davis wrote: The C++ support has been improved kind of piecemeal over time, and initially, none of it was documented. So, it wasn't exactly fully planned out when it was added. IIRC, it was added originally so that the dmd frontend

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Sunday, September 8, 2019 3:03:31 AM MDT Max Samukha via Digitalmars-d- learn wrote: > On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis > > wrote: > > On Saturday, September 7, 2019 3:40:58 PM MDT Exil via > > > > Digitalmars-d-learn wrote: > >> On Saturday, 7 September 2019 at

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, 7 September 2019 at 22:19:48 UTC, Jonathan M Davis wrote: On Saturday, September 7, 2019 3:40:58 PM MDT Exil via Digitalmars-d-learn wrote: On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: > @safe: > @system: > > then @system overrides @safe. Just to add

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, September 7, 2019 3:40:58 PM MDT Exil via Digitalmars-d-learn wrote: > On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis > > wrote: > > @safe: > > @system: > > > > then @system overrides @safe. > > Just to add onto this, you can't do: > > @safe @system void foo();

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: @safe: @system: then @system overrides @safe. Just to add onto this, you can't do: @safe @system void foo(); // error but you can do: extern(C++, ns1) extern(C++, ns2) void foo(); // ok

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, 7 September 2019 at 17:22:07 UTC, Jonathan M Davis wrote: makes no sense whatsoever IMHO. IIRC, this version of extern(C++) didn't go through the DIP process and was simply added via a PR. The original extern(C++) worked the same way. Since it was implemented in v2.066.0 by the

Re: Should an 'extern(C++, "ns"):' override previous ones in the same scope?

On Saturday, September 7, 2019 9:15:44 AM MDT Max Samukha via Digitalmars-d- learn wrote: > extern(C++, "ns1"): > extern(C++, "ns2"): // Not in nested scope. Should it supersede? > void foo(); > > pragma(msg, foo.mangleof); // _ZN3ns13ns23fooEv instead of > expected _ZN3ns23fooEv > > Is that by

Should an 'extern(C++, "ns"):' override previous ones in the same scope?

extern(C++, "ns1"): extern(C++, "ns2"): // Not in nested scope. Should it supersede? void foo(); pragma(msg, foo.mangleof); // _ZN3ns13ns23fooEv instead of expected _ZN3ns23fooEv Is that by design?

[Issue 19893] extern(C++, "ns") should count as module scope for version declarations

|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #9912 "Fix issue 19893 - extern(C++ 'ns') should count as module scope" was merged into master: - e8800cd11167c321fcc4de65530e849774dfb273 by Geod24: Fix issue 19893 - extern(C++ 'ns') should count as mo

[Issue 19920] __trait(parent, ...) broken with extern(C++,"ns") nested in scopes

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #9912 "Fix issue 19893 - extern(C++ 'ns') should count as module scope" was merged into master: - 6d0e856d1b863c586f88de7225b33ab480d604fd by Geod24: Fix issue 19920 - Wrong parent for `extern(C++, "ns&quo

[Issue 19920] __trait(parent, ...) broken with extern(C++,"ns") nested in scopes

updated dlang/dmd pull request #9912 "Fix issue 19893 - extern(C++ 'ns') should count as module scope" fixing this issue: - Fix issue 19920 - Wrong parent for `extern(C++, "ns")` nested in scope https://github.com/dlang/dmd/pull/9912 --

[Issue 19920] New: __trait(parent, ...) broken with extern(C++, "ns") nested in scopes

https://issues.dlang.org/show_bug.cgi?id=19920 Issue ID: 19920 Summary: __trait(parent, ...) broken with extern(C++,"ns") nested in scopes Product: D Version: D2 Hardware: All OS: All S

[Issue 19893] extern(C++, "ns") should count as module scope for version declarations

https://issues.dlang.org/show_bug.cgi?id=19893 --- Comment #3 from Dlang Bot --- @Geod24 created dlang/dmd pull request #9912 "Fix issue 19893 - extern(C++ 'ns') should count as module scope" fixing this issue: - Fix issue 19893 - extern(C++ 'ns') should count as module scope

[Issue 19893] extern(C++, "ns") should count as module scope for version declarations

https://issues.dlang.org/show_bug.cgi?id=19893 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com See Also|

[Issue 19893] extern(C++, "ns") should count as module scope for version declarations

https://issues.dlang.org/show_bug.cgi?id=19893 Nicholas Wilson changed: What|Removed |Added Summary|version declaration must be |extern(C++, "ns&quo

[Issue 19557] extern(C++, ns) and extern(C++, class) interact weird

|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #9892 "fix Issue 19557 - extern(C++, ns) and extern(C++, class) interact weird" was merged into stable: - 0b050b74bc70e4851eb4362a9e2144b933e7d8c9 by Nicholas Lindsay Wilson: fix Issue 19557 - extern(C++, ns) an

[Issue 19557] extern(C++, ns) and extern(C++, class) interact weird

--- @thewilsonator created dlang/dmd pull request #9892 "fix Issue 19557 - extern(C++, ns) and extern(C++, class) interact weird" fixing this issue: - fix Issue 19557 - extern(C++, ns) and extern(C++, class) interact weird https://github.com/dlang/dmd/pull/9892 --

[Issue 19557] New: extern(C++, ns) and extern(C++, class) interact weird

https://issues.dlang.org/show_bug.cgi?id=19557 Issue ID: 19557 Summary: extern(C++, ns) and extern(C++, class) interact weird Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: extern(C++, ns) is wrong

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 fo

Re: extern(C++, ns) is wrong

On Wed, 19 Sep 2018 at 13:15, Walter Bright via Digitalmars-d 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

[Issue 15512] extern(C++, ns) should consider taking a string

https://issues.dlang.org/show_bug.cgi?id=15512 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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 wrote: On Sunday, 16 September 2018 at 17:46:26 UTC, Steven Schveighoffer wrote: On 9/14/18 6:41 PM, Neia

Re: extern(C++, ns) is wrong

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 > > wrote: > > On Sunday, 16 September 2018 at 17:46:26 UTC, Steven > > > > Schveighoffer wrote: > > > On 9/14/18 6:41 PM, Neia Neutuladh wrote: > > >>

Re: extern(C++, ns) is wrong

On Mon, 17 Sep 2018 at 06:00, Atila Neves via Digitalmars-d 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)

[Issue 15512] extern(C++, ns) should consider taking a string

https://issues.dlang.org/show_bug.cgi?id=15512 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 15512] extern(C++, ns) should consider taking a string

https://issues.dlang.org/show_bug.cgi?id=15512 --- Comment #1 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/d9747003d45d205ff5348bfbe3f5d9779ae62732 Fix Issue 15512 - Implement better C++ name mangling feature.

Re: extern(C++, ns) is wrong

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

[Issue 15512] extern(C++, ns) should consider taking a string

https://issues.dlang.org/show_bug.cgi?id=15512 Manu changed: What|Removed |Added Keywords||C++ --

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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 funct

Re: extern(C++, ns) is wrong

> 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

Re: extern(C++, ns) is wrong

m> 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 sam

Re: extern(C++, ns) is wrong

edure, 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

Re: extern(C++, ns) is wrong

On Fri, 14 Sep 2018 at 07:55, 12345swordy via Digitalmars-d 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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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 t

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

On Thu, 13 Sep 2018 at 04:46, Danni Coy via Digitalmars-d wrote: > > On Thu, Sep 13, 2018 at 5:14 PM Jonathan M Davis via Digitalmars-d > wrote: >> >> The entire point of having extern(C++, "NS") would be to make it so that the >> _only_ thing that it wo

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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 s

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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/objec

Re: extern(C++, ns) is wrong

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 > wrote: > > > > > > > > So my understanding is that the main issue with extern(C++,"ns") is &

Re: extern(C++, ns) is wrong

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 > > wrote: > > So my understanding is that the main issue with extern(C++,"ns") is > > functions that have different C++ na

Re: extern(C++, ns) is wrong

On Tue, 11 Sep 2018 at 20:59, 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

Re: extern(C++, ns) is wrong

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 sim

Re: extern(C++, ns) is wrong

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/variabl

Re: extern(C++, ns) is wrong

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?

Re: extern(C++, ns) is wrong

On Mon, 10 Sep 2018 at 13:40, Carl Sturtivant via Digitalmars-d 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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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 wrote: [...] "A handwavy description"! What do you mean? I started the email with the code... if

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

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.

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d 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

Re: extern(C++, ns) is wrong

: > >> > On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d > >> > wrote: > >> >> [...] > >> > > >> > And yes, the example is actually complete. Again, but I'll > >> > simplify the filenames: > >> > >

Re: extern(C++, ns) is wrong

On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d 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

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

xample 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): > > >> [.

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

e 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 symb

Re: extern(C++, ns) is wrong

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 ?

Re: extern(C++, ns) is wrong

> 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

Re: extern(C++, ns) is wrong

On Tue, 4 Sep 2018 at 16:35, Walter Bright via Digitalmars-d 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:

Re: extern(C++, ns) is wrong

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):

Re: extern(C++, ns) is wrong

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

Re: extern(C++, ns) is wrong

On Tue, 4 Sep 2018 at 16:00, Neia Neutuladh via Digitalmars-d 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

Re: extern(C++, ns) is wrong

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

extern(C++, ns) is wrong

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`

[Issue 15512] extern(C++, ns) should consider taking a string

https://issues.dlang.org/show_bug.cgi?id=15512 Manu changed: What|Removed |Added Keywords||industry --

Re: extern(C++, ns)

On Thursday, 7 January 2016 at 18:17:24 UTC, Walter Bright wrote: On 1/7/2016 9:02 AM, Carl Sturtivant wrote: I should have noticed this too; so in fact the current design can be used ignoring the scope modeling the C++ namespace. If the details of using such an external name in that fashion

Re: extern(C++, ns)

On Saturday, 30 January 2016 at 21:06:22 UTC, Carl Sturtivant wrote: So what do you make of Manu's last post? http://forum.dlang.org/post/mailman.3421.1452230079.22025.digitalmar...@puremagic.com Specifically, he gives examples of name collisions and scope problems that apparently could be

Re: extern(C++, ns)

On Friday, 22 January 2016 at 17:04:00 UTC, Jacob Carlborg wrote: Unfortunately that's not how it works with D. If Andrei or Walter have a proposal it's up to the community to provide compelling evidence why it _should not_ be added. If the community has a proposal it's up to the community to

Re: extern(C++, ns)

On Thursday, 21 January 2016 at 00:43:13 UTC, David Nadlinger wrote: If you want to split up the interface to a C++ namespace among different modules, then the different symbols will *always* reside in different fully qualified scopes – with or without additional scopes being introduced by

Re: extern(C++, ns)

On Sunday, 31 January 2016 at 01:12:11 UTC, Carl Sturtivant wrote: This is the nub of the problem, and it's been stated by several people in several different ways in this thread. It means that a C++ namespace which is a single scope, is mapped into one scope per module in D. The C++

Re: extern(C++, ns)

D generally doesn't allow shadowing of names inside inner scopes. int x; for (int i=0; i<max; i++) { int x = i*2-1; } works in a lot of languages but not D. int x; extern (C) int x; doesn't work. having int x; extern (C++,ns) int x; work might be useful but to me seems inconsist

Re: extern(C++, ns)

On 2016-01-21 00:50, David Nadlinger wrote: To add a new feature to the language, the onus is on you to provide compelling evidence why it is necessary to have. You need to show that there is a "serious problem" with just using the native D namespacing scheme (modules) for the purpose, not the

Re: extern(C++, ns)

On Thursday, 21 January 2016 at 00:51:34 UTC, Anon wrote: What would you all say to the following proposal (and should I make a DIP?) 1. deprecate pragma(mangle) 2. deprecate extern(C++, ns) 3. deprecate @selector() 4. Introduce a better, more general extern() as follows: extern

Re: extern(C++, ns)

On 21/01/2016 9:15 AM, Walter Bright wrote: On 1/20/2016 8:38 AM, Marc Schütz wrote: IMO his description was already quite clear, but here you are: What's missing is why this is a *serious* problem. All you've got to do is add a qualifier. The *serious* problem is that the added scope does

Re: extern(C++, ns)

On 1/20/2016 3:53 PM, tsbockman wrote: The thought of needing to do that for (potentially) every single symbol being imported is depressing. What happened to DRY? Since it is completely mechanical, it's an ideal candidate for writing a metafunction to do it: module stl--

Re: extern(C++, ns)

I'm not sure what situation you're imagining where modules would be created with the same names...? How do you plan to map C++'s standard lib ? One giant hundred of thousands of line C++ file ? Surely it would map by file. #include -> import stl.vector; #include -> import stl.map;

Re: extern(C++, ns)

On 1/20/2016 4:51 PM, Anon wrote: What would you all say to the following proposal (and should I make a DIP?) DIPs are always welcome.

Re: extern(C++, ns)

On Thursday, 21 January 2016 at 01:37:12 UTC, Walter Bright wrote: On 1/20/2016 4:51 PM, Anon wrote: What would you all say to the following proposal (and should I make a DIP?) DIPs are always welcome. Done. http://forum.dlang.org/post/ldtluvnhuznvbebcb...@forum.dlang.org

Re: extern(C++, ns)

What would you all say to the following proposal (and should I make a DIP?) 1. deprecate pragma(mangle) 2. deprecate extern(C++, ns) 3. deprecate @selector() 4. Introduce a better, more general extern() as follows: extern ( [, ] ) Which would *only* influence mangling and calling

Re: extern(C++, ns)

ear. If we had extern(C++, "ns") just affect the mangling, the need for adding extra qualifiers wouldn't exist in the first place. — David

Re: extern(C++, ns)

On Wednesday, 20 January 2016 at 12:47:44 UTC, Manu wrote: 2. Multiple modules cannot have the same name in D. I'm not sure what situation you're imagining where modules would be created with the same names...? How do you plan to map C++'s standard lib ? One giant hundred of thousands

Re: extern(C++, ns)

On Wednesday, 20 January 2016 at 17:25:56 UTC, JohnCK wrote: On Wednesday, 20 January 2016 at 16:38:19 UTC, Marc Schütz wrote: I think the first error is correct: bar(); // Error: b.bar at b.d(6) conflicts with a.ns.bar at a.d(5) Yes, I put this one in to show why the next lines

Re: extern(C++, ns)

keywords as C/C++ identifiers. https://issues.dlang.org/show_bug.cgi?id=15587 You claim this is a problem that must desperately be solved: int x; extern(C++, ns) int x; The solution arrives at basically the same problem

Re: extern(C++, ns)

On 01/20/2016 09:56 PM, Walter Bright wrote: On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote: -- name.x.d module name.x; -- name.y.d module name.y; import name.x; extern(C++, name) int x; This won't work ...

  1   2   3   4   >