On 3 January 2016 at 15:34, Rikki Cattermole via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> On 03/01/16 6:26 PM, Manu via Digitalmars-d wrote: > >> On 3 January 2016 at 15:17, Rikki Cattermole via Digitalmars-d >> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: >> >> Ok, so what I gathered from that is that if a D package/module >> matches a C++ one in scope, D will only be checked. >> >> >> No, you name conflict error. But that's not the main problem I'm talking >> about, which is that namespace scopes are created and break everything. >> >> The obvious answer would be to rename the D side, but that really >> isn't good enough. >> >> >> You don't just go and rename an entire existing project, which is a lib >> in this case (so, also rename all the clients...?) because you need to >> type extern(C++) somewhere :/ >> > > Hang on I just tried this on Windows: > > module ns.m; > > import x.y; > // import x.y : ns.Y; // doesn't work grr > import x.y : Y; > > > module x.y; > > extern(C++, ns) { > struct Y { > } > } > > > Does this work for you? > The short answer is, "most of the time". I've been using recursive modules to place extern(C++) declarations in a sensible scope quite a lot. It breaks sometimes, not sure why... suspect it's related to forward referencing, or multiple/semi-circular imports.
