Re: extern(C++, ns)

[Rikki Cattermole via Digitalmars-d]

On 03/01/16 6:51 PM, Manu via Digitalmars-d wrote:

On 3 January 2016 at 15:45, Manu <turkey...@gmail.com
<mailto:turkey...@gmail.com>> wrote:

    On 3 January 2016 at 15:34, Rikki Cattermole via Digitalmars-d
    <digitalmars-d@puremagic.com <mailto: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>
            <mailto: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.


For instance, connecting to the C++ string lib:

module libep.string;
public import libep.c.string : BaseString, MutableString, SharedString;
alias String = BaseString!char;
alias WString = BaseString!wchar;
alias DString = BaseString!dchar;

Those don't like to be imported that way: Error: template instance
BaseString!char BaseString is not a template declaration, it is a alias
If I instead:

module libep.string;
static import libep.c.string;
alias BaseString = libep.c.string.BaseString;
alias MutableString = libep.c.string.MutableString;
alias SharedString = libep.c.string.SharedString;
alias String = BaseString!char;
alias WString = BaseString!wchar;
alias DString = BaseString!dchar;

That works in this case. Other cases are different, eg:

module libep.variant;
public import libep.c.variant : Variant;

That one works.

Can you please come on IRC?
It will be a little easier to solve this.