On 4/3/14, 4:19 AM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:lhi1lt$269h$1@digitalmars.com...
>
>> Here's Andrei's proposal:
>>
>>      extern (C++) template nspace() {
>>          int foo();
>>      }
>
> This is really ugly and complicated.
>
> Why not just
>
> pragma(cpp_namespace, "outer")
> {
>     pragma(cpp_namespace, "inner")
>     {
>         extern(C++) void func();
>     }
> }
>
> which is trivial to implement and doesn't require parser or semantic
> changes?

I don't quite see how one is ugly and complicated and the other is... pretty and simple? Anyhow de gustibus.

> Adding syntax for actual namespaces to D is a different beast and IMO
> not worthwhile.

Agreed.


Andrei

On 2014-04-03 19:43:23 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 4/3/2014 3:36 AM, Michel Fortin wrote:
>> I'd tend to simply implement extern(C++, namespace.here), which should work fine
>> to wrap single-namespace cpp files, and wait to see what are the actual friction
>> points before introducing more (people can experiment with structs or other
>> modules meanwhile).
> 
> You have a good point in that to go all the way with namespaces, we'd have to implement Koenig lookup and support insertion of names into previous namespaces.
> 
> I can't see this happening in D.

Me neither.

> But I don't see that as much of an argument to not do simple scoping with namespace lookup.

What I'm saying is that it should be optional to create a new scope to declare a C++ function from a namespace. In other words you need to be able to put the function at module scope in D.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Thursday, 3 April 2014 at 11:19:53 UTC, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:lhi1lt$269h$1@digitalmars.com...
>
>> Here's Andrei's proposal:
>>
>>     extern (C++) template nspace() {
>>         int foo();
>>     }
>
> This is really ugly and complicated.
>
> Why not just
>
> pragma(cpp_namespace, "outer")
> {
>    pragma(cpp_namespace, "inner")
>    {
>        extern(C++) void func();
>    }
> }
>
> which is trivial to implement and doesn't require parser or semantic changes?
>
> Adding syntax for actual namespaces to D is a different beast and IMO not worthwhile.


IMO I don't think pragmas are meant to this kind of uses, extern(C++) already exists and makes more sense.

On Thu, Apr 03, 2014 at 12:43:59PM -0700, Walter Bright wrote:
> On 4/3/2014 4:06 AM, Daniel Kozák wrote:
> >I think we should distinguish modules lookup from namespaces lookup. Something like this:
> >
> >A.B.foo() // call foo function from module/struct/class A and B
> >#A.#B.foo // call foo function from namespaces A and B
> >or
> >A::B.foo // call foo function from namespaces A and B
> >or
> >/A/B.foo // call foo function from namespaces A and B
> 
> 
> Please, no!

The current situation where module/scope qualifiers clash with UFCS sux, though.

	static import std.algorithm;
	...
	auto myRange = ...;
	//myRange.std.algorithm.find(...);	// NG :-(

	alias find = std.algorithm.find;
	myRange.find(...);			// OK

But this is kinda tangential to this topic. :P


T

-- 
My program has no bugs! Only undocumented features...

On Wednesday, 2 April 2014 at 22:06:53 UTC, Walter Bright wrote:
> Here's Andrei's proposal:
>
>     extern (C++) template nspace() {
>         int foo();
>     }
>
> It would be accessed in D by:
>
>    nspace!().foo();
>
> A possible enhancement would be to allow (for all templates with no parameters):
>
>     nspace.foo();
>
> Note that:
>
>     template nspace() {
>         extern (C++) int foo();
>     }
>
> would not put foo() in a C++ namespace, although it would still be accessed from D as:
>
>     nspace.foo();
>
> One downside of this proposal is that if we ever (perish the thought!) attempted to interface to C++ templates, this design would preclude that.

I'm not familiar with usual C++ mangling as much as D. Are
template and namespace mangled the same way ?

"Andrei Alexandrescu"  wrote in message news:lhkebg$1i1p$1@digitalmars.com...

>>
>>      extern (C++) template nspace() {
>>          int foo();
>>      }
>
> This is really ugly and complicated.
>

> I don't quite see how one is ugly and complicated and the other is... pretty and simple? Anyhow de gustibus.

Stuff inside the template will only be instantiated when used.  That's fine when it's just a prototype of a C++ function to be called from D, but much less useful when the implementation is in D and the use is from C++.

It can conflict with the eponymous template syntax - D would not be able to tell the difference between a templated function and a function inside a namespace with the same name.

It forces this organisation for all symbols that use C++ namespaces.

If you define functions in the same namespace in different modules the template symbols will conflict and you will have to use fully-qualified names.

On the other side, in D modules are used for symbol organisation.  It's powerful enough that you can get namespace::function to match library.module.function (and I expect you can force use of the namespace through clever use of static renamed imports).

The missing part is getting the mangling right, and a pragma is the least intrusive way I can imagine to do that. 

"Walter Bright"  wrote in message news:lhi1lt$269h$1@digitalmars.com...
> Here's Andrei's proposal:
>
>     extern (C++) template nspace() {
>         int foo();
>     }
This seems misleading to readers of future code.
- An "extern (C++)" function lets you use a C++ function.
- An "extern (C++)" interface lets you use a C++ interface (declared as a class, as is always the case in C++).
- An "extern (C++)" template lets you use a C++... namespace?

On Thursday, 3 April 2014 at 11:19:53 UTC, Daniel Murphy wrote:
> Why not just
>
> pragma(cpp_namespace, "outer")
> {
>    pragma(cpp_namespace, "inner")
>    {
>        extern(C++) void func();
>    }
> }
This really has only one obvious interpretation (the correct one), and seems to be a rather harmless addition to the language.

It also fulfills the goal of allowing access to C++ libraries without cluttering D with C++ language features.  I don't want to have to explain to my students the difference between "modules" "D templates" and "C++ namespace templates" (it reminds me of old- and new-style classes in Python 2).

On 4/3/2014 5:47 PM, deadalnix wrote:
> I'm not familiar with usual C++ mangling as much as D. Are
> template and namespace mangled the same way ?

No.

Late to the thread, my short opinion:

extern(C++ namespace::path) looks best. It should only affect mangling and have no impact on fully qualified name on D side. Most KISS solution I have read in the thread.

On 4/3/14, 11:59 PM, Mason McGill wrote:
> "Walter Bright"  wrote in message news:lhi1lt$269h$1@digitalmars.com...
>> Here's Andrei's proposal:
>>
>>     extern (C++) template nspace() {
>>         int foo();
>>     }
> This seems misleading to readers of future code.
> - An "extern (C++)" function lets you use a C++ function.
> - An "extern (C++)" interface lets you use a C++ interface (declared as
> a class, as is always the case in C++).
> - An "extern (C++)" template lets you use a C++... namespace?
>
> On Thursday, 3 April 2014 at 11:19:53 UTC, Daniel Murphy wrote:
>> Why not just
>>
>> pragma(cpp_namespace, "outer")
>> {
>>    pragma(cpp_namespace, "inner")
>>    {
>>        extern(C++) void func();
>>    }
>> }
> This really has only one obvious interpretation (the correct one), and
> seems to be a rather harmless addition to the language.
>
> It also fulfills the goal of allowing access to C++ libraries without
> cluttering D with C++ language features.  I don't want to have to
> explain to my students the difference between "modules" "D templates"
> and "C++ namespace templates" (it reminds me of old- and new-style
> classes in Python 2).

The above well describes my first reaction to the syntax (except the part about having students). And my second reaction too, in fact.