On Sunday, 29 November 2015 at 04:57:28 UTC, Walter Bright wrote:
> D does not support C++ semantics. You cannot split namespaces into multiple files in D, nor can you add symbols to an existing namespace. For namespace NS, all the declarations in NS have to be in one file and between the { }, just like any other scope in D.

While I don't disagree with trying to limit how much of C++ gets dragged into D to support linking with C++ code, I don't see how this approach with namespaces is tenable in anything much more complicated than a toy example. C++ namespaces aren't used at all like D modules. Entire libraries are put into a single namespace. For instance, are you suggesting that we put all of the bindings for C++'s standard library in a single file? Large libraries such as Boost or Qt do often split up their namespaces into sub-namespaces, but they're still usually far larger than anyone would want to stick in a single file.

It seems to me that the only way that the current behavior stands any chance of being tenable is if almost no one is using C++ bindings, and when they do, they keep them to an absolute bare minimum. It certainly doesn't fly well with binding something like the STL or Qt.

- Jonathan M Davis

On Sunday, 29 November 2015 at 12:39:14 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 29 November 2015 at 04:57:28 UTC, Walter Bright wrote:
>> Aliases do not change access permissions. They are just aliases.
>
> Note that this is a problem beyond Manu's use-case.  Example: subtyping via alias this currently requires the alias'd entity to be public, contra the example given on TDPL p.231 (see https://issues.dlang.org/show_bug.cgi?id=10996 for details).
>
> This means that to use subtyping in practice requires internal implementation details to be revealed to the user, which isn't very nice :-(

As long as aliases effectively disappear in the compiler once a replacement has been made, and they don't end up in error messages, allowing aliases to muck with anything about the original symbol seems like a recipe for disaster, though I can certainly see why folks would want it (and arguably, it would be a lot more user-friendly if the aliases showed up in the error messages along with the original symbol rather than outright disappearing).

- Jonathan M Davis

On 11/29/2015 05:57 AM, Walter Bright wrote:
>
> D does not support C++ semantics. You cannot split namespaces into
> multiple files in D, nor can you add symbols to an existing namespace.
> For namespace NS, all the declarations in NS have to be in one file and
> between the { }, just like any other scope in D.
>

It's about namespace overloading.
The following works, even though no scopes are actually extended with new symbols.

module other;
template foo(){ // a scope
    void foo(){}
}
// ----
import other;
alias foo=other.foo;
template foo(){ // another scope
    void foo(int){}
}
void main(){
    foo(); // successful
    foo(2); // ditto
}

On 11/29/2015 05:40 AM, Manu via Digitalmars-d wrote:
>
> The trouble mostly appears in this situation:
>
> file1.d
>    extern(C++, NS) struct X;
>
> file2.d
>    extern(C++, NS) struct Y;
>
> file3.d
>    import file1, file2;
>    X x; // nope
>    Y y; // nope

Those two actually work for me.

>    NS.X x; // NS has multiple definitions...
>    NS.Y y; // NS has multiple definitions...

On 11/29/2015 12:22 PM, Daniel N wrote:
> On Sunday, 29 November 2015 at 10:58:48 UTC, Manu wrote:
>> On 29 November 2015 at 20:17, Iain Buclaw via Digitalmars-d
>>> I think your idea with aliases was just wishful thinking, aliases
>>> themselves never worked like that.
>>
>> I thought aliases did produce a symbol in the scope they are declared?
>> Or do you mean with the private thing? Yeah...
>> Aliases are often used to sort out these sorts of scope/namespacing
>> issues, I've seen it come up lots of times.
>
> I remember when this feature was under discussion, I tried to argue
> against extern c++ creating a new scope, but alas no avail. So my
> current workaround looks something like this(but I didn't use it on a
> large scale yet):
>
> private static struct Hidden
> {
> public:
>      extern(C++, std) int fun();
> }
>
> // autogenerate all aliases with 'static foreach'?
> alias fun = Hidden.std.fun;
>
> if only static foreach would get accepted one day...
>

It is mostly about implementation now (and figuring out a couple of corner cases, for which the first version could just deny support).


Something like this seems to be enough for your needs though:

mixin({string s;
    foreach(m;__traits(allMembers,std))
        s~=`alias `~m~`=std.`~m~`;`;
    return s;
}());

On Sunday, 29 November 2015 at 13:18:16 UTC, Timon Gehr wrote:
> It is mostly about implementation now (and figuring out a couple of corner cases, for which the first version could just deny support).
>
Awesome, much looking forwards to it!

> Something like this seems to be enough for your needs though:
>
> mixin({string s;
>     foreach(m;__traits(allMembers,std))
>         s~=`alias `~m~`=std.`~m~`;`;
>     return s;
> }());

You're right, thanks! Works like a charm. :)

On 11/28/2015 8:40 PM, Manu via Digitalmars-d wrote:
> The trouble mostly appears in this situation:
>
> file1.d
>    extern(C++, NS) struct X;
>
> file2.d
>    extern(C++, NS) struct Y;
>
> file3.d
>    import file1, file2;
>    X x; // nope
>    Y y; // nope
>    NS.X x; // NS has multiple definitions...
>    NS.Y y; // NS has multiple definitions...

    file1.NS.X x;
    file2.NS.Y y;

works.

On 11/29/2015 1:56 AM, Manu via Digitalmars-d wrote:
> Options?

I can't do anything with what you describe. Need reproducible test cases, not handwaving. It should also be in a separate thread rather than mixed up with the other issue.

On 11/28/2015 9:17 PM, Manu via Digitalmars-d wrote:
> On 29 November 2015 at 14:57, Walter Bright via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> D does not support C++ semantics. You cannot split namespaces into multiple
>> files in D, nor can you add symbols to an existing namespace. For namespace
>> NS, all the declarations in NS have to be in one file and between the { },
>> just like any other scope in D.
>
> Then the feature fails. You can't put the entire STL in one file.
> C++ doesn't namespace per file, it generally namespaces per project...
> so this is the common case; every module define symbols in the same
> C++ namespace.

You can also do this:

extern (C++, NS)
{
    mixin(import("file1.d"));
    mixin(import("file2.d"));
}



> Maybe a special case for C++ namespaces?

Please, no. Unending confusion and bugs will result.


> C++ tends to namespace everything with the same namespace, and that
> means either I implement the entire C++ library in a single module

You only need the declarations, not the implementations.

On 11/29/2015 2:40 AM, Iain Buclaw via Digitalmars-d wrote:
> On 29 Nov 2015 11:30 am, "Jacob Carlborg via Digitalmars-d"
> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
>  >
>  > On 2015-11-29 11:19, Iain Buclaw via Digitalmars-d wrote:
>  >
>  >> I keep telling them to fix that.  My suggestion of replacing them with
>  >> meaningful errors was rejected.
>  >
>  >
>  > "rejected", what!! Any assertion in the compiler is a bug. Or was that not
> from the compiler?
>  >
>
> Someone put in those ICE's on the promise that at some point it would be
> detected in semantic pass before the symbol mangling was requested.  That
> promise was never kept.
>
> For reference (or if you enjoy time travelling)
> https://github.com/D-Programming-Language/dmd/pull/4661

I commented there:

"And any test cases that trigger these ICEs should be filed in bugzilla."

What are the bugzilla issues?