On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Using named mixin templates for pure scope resolution is side effect and should be discouraged in any reasonable code.

There's also the un-instantiable class trick:

-----
final abstract class Scope
{
static:
}
-----

A struct-based version is also possible. It's used in Phobos and other libraries. There's a need for scoping symbols other than in modules, but I'm not a fan of pushing C++ features in D. Not unless we have a really solid DIP.

Idealism aside, modules have some implementation issues right now which force people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy.

On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
> There's a need for scoping symbols other than in modules,

What is that need?


> Not unless we have a really solid DIP.

What's wrong with the DIP?


> Idealism aside, modules have some implementation issues right now
> which force people to use workarounds like named mixins or the above
> trick, e.g. package access not being propagated up/down a hierarchy.

??

Walter Bright <newshound2@digitalmars.com> wrote:
> On 4/26/2014 12:27 PM, Daniel Murphy wrote:
>> We already have a feature to manage conflicts and organisation in D code - modules!
> 
> True. But what D doesn't have is a global namespace. I don't propose one
> for D, but C++ symbols may appear in the C++ global namespace, or in a
> C++ namespace. So using D modules to represent C++ namespaces has a problem.

But C++ namespaces and D modules don't have to match at all. You can import
any C++ function from an arbitrary namespace into any D module, just as you
like.
Also, I guess there is a reason, why D doesn't have a global module.

Tobi

"Walter Bright"  wrote in message news:ljie28$7ei$1@digitalmars.com...

> I am not seeing an actual proposal. If I missed it, please point me at it.

You missed it.  `pragma(cpp_namespace, "...")` and all enclosed C++ declarations are mangled accordingly.  No other changes. 

On 4/27/14, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
>> There's a need for scoping symbols other than in modules,
>
> What is that need?

Here's some examples from Phobos:

std.uni.unicode is a lowercase-named struct because it's supposed to be used as a namespace:

-----
auto ascii = unicode.ASCII;
-----

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
-----

I've seen other libraries use this sort of trick. E.g. the D1 Harmonia GUI library, but I'm pretty sure I saw it in some D2 libraries.

>> Not unless we have a really solid DIP.
> What's wrong with the DIP?

It's barely 10 sentences long, I've seen forum posts longer than this. It's supposed to be solid, with lots of example code, and also any drawbacks or potential conflicts being listed (you list none at all). It doesn't have a FAQ, links to other competing proposals, etc. And arbitrary decisions are listed in that DIP without any rationale whatsoever, e.g.:

- Unlike C++, namespaces in D will be 'closed' meaning that new declarations cannot be inserted into a namespace after the closing } => rationale?

- C++ Argument Dependent Lookup (aka "Koenig Lookup") will not be
supported.  => rationale?

There are other well-written DIPs in there for reference.

>> Idealism aside, modules have some implementation issues right now which force people to use workarounds like named mixins or the above trick, e.g. package access not being propagated up/down a hierarchy.
>
> ??

Here's the report: https://issues.dlang.org/show_bug.cgi?id=2529

Don's conclusion is what I agree with: https://issues.dlang.org/show_bug.cgi?id=2529#c1

Quote: "the existing 'package' semantics force you to a flat hierarchy."

Also, package access can be worked around in user-code: https://issues.dlang.org/show_bug.cgi?id=9381

27-Apr-2014 13:04, Andrej Mitrovic via Digitalmars-d пишет:
> On 4/27/14, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On 4/27/2014 1:16 AM, Andrej Mitrovic via Digitalmars-d wrote:
>>> There's a need for scoping symbols other than in modules,
>>
>> What is that need?
>
> Here's some examples from Phobos:
>
> std.uni.unicode is a lowercase-named struct because it's supposed to
> be used as a namespace:
>
> -----
> auto ascii = unicode.ASCII;
> -----

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.



-- 
Dmitry Olshansky

Walter Bright <newshound2@digitalmars.com> wrote:
> On 4/26/2014 4:01 AM, Mike wrote:
>> pragma(cpp_namespace, "A.B")
>> extern(C++) void f() {}
> 
> This implies that it only affects the name mangling. There needs to be a scope created, too.

I think that's the crucial point here. Most people that disagree with your
proposal disagree exactly with that.
Scope should be created by modules and only modules.

Tobi

On Sunday, 27 April 2014 at 00:21:19 UTC, Aleksandar Ruzicic wrote:
> 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(); }}
>
> Or maybe reuse existing keywords:
>
>     extern (C++) scope N.M { void foo(); }
>
> or
>
>     extern (C++) module interface N.M { void foo(); }
>
>
> or something along those lines.. but maybe it should look a bit ugly :)


 extern (C++)!("N.M") { void foo(); }

;)

On Sunday, 27 April 2014 at 08:16:58 UTC, Andrej Mitrovic via Digitalmars-d wrote:
> On 4/27/14, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> Using named mixin templates for pure scope resolution is side
>> effect and should be discouraged in any reasonable code.
>
> There's also the un-instantiable class trick:
>
> -----
> final abstract class Scope
> {
> static:
> }
> -----
>
> A struct-based version is also possible. It's used in Phobos and other
> libraries. There's a need for scoping symbols other than in modules,
> but I'm not a fan of pushing C++ features in D. Not unless we have a
> really solid DIP.

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.

> Idealism aside, modules have some implementation issues right now
> which force people to use workarounds like named mixins or the above
> trick, e.g. package access not being propagated up/down a hierarchy.

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.

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).