On Sunday, 27 April 2014 at 13:43:13 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> I believe this is a temporary workaround. Once bugs and
>> deficiencies of existing module system will be taken care of,
>> there won't be any need in using namespace emulation.
>
> That's not true. Remember that when you're importing into a module
> you're import all symbols from that module into the current namespace.
> With symbols in aggregates you're forced to qualify the symbol with
> the name of the scope it's located in. One exception is the with()
> statement, but that can only be used in limited contexts (and is buggy
> as hell anyway).

This is why fixing selective / renamed imports is so important. Once those are polished I'd consider using plain import anywhere but in quick scripts to be a bad style.

On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> This pops up very often so I have just went and implemented proof of concept for package(pkg1.pkg2.pkg3) protection attribute syntax. Was relatively straightforward, will do a PR soon-ish after some cleanup.

Yeah. It's not so difficult to implement this stuff, the problem is agreeing to something (and getting a green light from W&A).

On Sunday, 27 April 2014 at 13:49:15 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> This pops up very often so I have just went and implemented proof
>> of concept for package(pkg1.pkg2.pkg3) protection attribute
>> syntax. Was relatively straightforward, will do a PR soon-ish
>> after some cleanup.
>
> Yeah. It's not so difficult to implement this stuff, the problem is
> agreeing to something (and getting a green light from W&A).

Hey, I am trying to be an optimist here for a minute! And you are not helping ;)

>     extern (C++, N.M) { void foo(); }
>
>     extern (C++) namespace N { namespace M { void foo(); }}
Excellent.  Solves the problem, doesn't add new language elements.

On Saturday, 26 April 2014 at 23:32:42 UTC, Walter Bright wrote:
> Since the namespace keyword doesn't seem to be gaining much traction, an alternative syntax would be:
>
>     extern (C++, N.M) { void foo(); }
>
> which would be semantically equivalent to the previous:
>
>     extern (C++) namespace N { namespace M { void foo(); }}

LGTM.

"Jason King"  wrote in message news:cgcqomgrrtujzckvuvyv@forum.dlang.org...

> >     extern (C++, N.M) { void foo(); }
> >
> >     extern (C++) namespace N { namespace M { void foo(); }}
>
> Excellent.  Solves the problem, doesn't add new language elements.

It adds a new scoping rule, and new syntax.  Neither of those things are necessary. 

On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Hey, I am trying to be an optimist here for a minute! And you are not helping ;)

You must be new around here! I've had plenty of pulls being stuck in the tarpit and then rejected. :)

But actually, package(foo.bar) is something I've seen mentioned before in some bug report. Or maybe we just had the same idea at some point. Good luck! :P

Am Sun, 27 Apr 2014 00:08:17 -0700
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 4/26/2014 11:22 PM, Daniel Murphy wrote:
> > I am NOT suggesting module name and namespace mangling should be tied together. Use D modules for symbol organisation, and add a simple feature for specifying a C++ namespace when required.
> 
> The 'namespace' feature actually does work analogously to modules.

Does that mean the full name in D would become something like this?:

[D module     ] [C++ namespace] company.project.company.project.func

-- 
Marco

On 4/27/2014 2:08 AM, Dmitry Olshansky wrote:
> Technically it's a functor that works like this:
>
> auto ascii = unicode("ASCII");
>
> Then opDispatch is just a nice bonus to go with it, and struct is the only shop
> to offer such goodies.

So it's not just a namespace!

On 4/27/2014 2:04 AM, Andrej Mitrovic via Digitalmars-d wrote:
> And here's std.datetime using a similar trick:
>
> -----
> /++
>      Effectively a namespace to make it clear that the methods it contains are
>      getting the time from the system clock. It cannot be instantiated.
>   +/
> final class Clock
> -----

When you find yourself doing things like that, seriously consider creating a new module to do it, called "clock".

std.datetime is a giant kitchen sink. This is not the best way to organize things. Using smaller modules under packages is a much better way.