Bug 13183 – C++ namespace should not conflict with import root package
Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-07-22T11:32:00Z
Last change time
2017-02-14T21:49:32Z
Keywords
C++
Assigned to
nobody
Creator
verylonglogin.reg
Comments
Comment #0 by verylonglogin.reg — 2014-07-22T11:32:15Z
The fact C++ root namespace conflicts with import root package makes it hard to have same root namespace in C++ codebase.
This code should compile:
---
import abba.m;
extern(C++, abba) { }
---
main.d(2): Error: namespace main.abba conflicts with import main.abba at main.d(1)
---
Comment #1 by redballoon36 — 2015-01-15T16:58:40Z
I'd like to add a more compelling use case:
import std.string;
extern(C++, std) { }
It's not possible to use the D standard library in the same modules as the C++ standard library.
Tested in dmd 2.066.1
Comment #2 by dfj1esp02 — 2015-01-26T15:52:46Z
Does this work?
---
import dstd = std.string;
extern(C++, std) { }
---
Comment #3 by redballoon36 — 2015-03-28T05:34:48Z
Yes, that does work. Thanks for the workaround. I'm now a lot less concerned about this but still think it should remain open.
Comment #4 by dfj1esp02 — 2015-09-22T12:42:06Z
*** Issue 15098 has been marked as a duplicate of this issue. ***
Comment #5 by dfj1esp02 — 2017-02-13T12:52:09Z
*** Issue 17178 has been marked as a duplicate of this issue. ***
Comment #6 by bugzilla — 2017-02-14T09:37:49Z
The workaround looks good.
Comment #7 by timothee.cour2 — 2017-02-14T09:50:07Z
what do you mean by `The workaround looks good.`?
It makes it difficult to integrate; that prevents any direct `import foo` which could in turn import `std.something` so forces one to do all sorts of convolutions
Comment #8 by dfj1esp02 — 2017-02-14T11:32:54Z
AIU, this can't work because C++ namespaces are added to D symbol table. Manu proposed to not add C++ namespaces to D symbol table, use them for mangling only, this would also allow multiple declarations of the same C++ namespace. Was it rejected?
Comment #9 by bugzilla — 2017-02-14T21:43:36Z
(In reply to anonymous4 from comment #8)
> AIU, this can't work because C++ namespaces are added to D symbol table.
> Manu proposed to not add C++ namespaces to D symbol table, use them for
> mangling only, this would also allow multiple declarations of the same C++
> namespace. Was it rejected?
Manu's proposal was rejected. There was a discussion thread about it, sorry, I don't have a link handy.
Comment #10 by bugzilla — 2017-02-14T21:49:32Z
(In reply to Timothee Cour from comment #7)
> what do you mean by `The workaround looks good.`?
It's a workable solution.
> It makes it difficult to integrate; that prevents any direct `import foo`
> which could in turn import `std.something` so forces one to do all sorts of
> convolutions
There always is the potential of name collisions when using interfacing with libraries and things that were not designed to work together. This is a general problem, and is not specific to C++ compatibility. The import renaming feature is a reasonable way to deal with it.
I suggest as a matter of good practice to minimize the size and complexity of modules that have to import both. I've found this to be successful when dealing with #include <windows.h>, rather than the common practice of #include <windows.h> in every file.