On 04/03/2014 09:55 PM, Andrei Alexandrescu wrote:
> ...
> Anyhow de gustibus.
>

There's good and bad taste.

Not that I ever do this, but I think you need to deal with this C++ construct:

namespace exposed_ns {
  using namespace internal_ns_2134zxdssdffrandomblablah;
  using namespace internal_ns_2634zasdsfsdrandomblablah;
  using namespace internal_ns_2993adsfadsfrandomblablah;
}

To do this in D you would have to be able to set up a search sequence as an alias somehow.

On Saturday, 5 April 2014 at 13:11:27 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 5 April 2014 at 12:58:54 UTC, Dicebot wrote:
>> It shouldn't. The fact how entity is exposed via some external binary interface should not have any notable impact on D side of things (unless you dwell into ABI realm).
>
> This is a design philosophical issue, you can make it normative if you want, but only if it is consistent with the overall design philosophy.

This is very practical thing. By introducing special constructs to support some foreign language you open the can of worms. Where does one stop? Should we also expect adding some new idioms for better JNI support? Or Python? I can't see any reason why C++ has to be any special and you can't nicely support them all. We don't even truly do this for C and this the only real ABI standard.

On Saturday, 5 April 2014 at 15:24:32 UTC, Dicebot wrote:
> This is very practical thing. By introducing special constructs to support some foreign language you open the can of worms.

Yep, but I believe C++ is increasingly going to replace C as a language for writing basic libraries and engines in the next few decades. Which isn't great for interop, but a trend still.

On Saturday, 5 April 2014 at 15:24:32 UTC, Dicebot wrote:
> This is very practical thing. By introducing special constructs to support some foreign language you open the can of worms. Where does one stop? Should we also expect adding some new idioms for better JNI support? Or Python? I can't see any reason why C++ has to be any special and you can't nicely support them all. We don't even truly do this for C and this the only real ABI standard.

Another way to put this is that D is its own language, not a C++ extension.  IMO, an FFI should make interoperability possible via ABI matching, but it should not compromise the language (by making its scoping rules more complicated, introducing redundant constructs, or introducing a new token ("::") that could be used for another feature).

On 4/5/2014 8:24 AM, Dicebot wrote:
> This is very practical thing. By introducing special constructs to support some
> foreign language you open the can of worms. Where does one stop? Should we also
> expect adding some new idioms for better JNI support? Or Python? I can't see any
> reason why C++ has to be any special and you can't nicely support them all. We
> don't even truly do this for C and this the only real ABI standard.

A very good question. Some points to consider:

1. D is supposed to be a practical language, and be designed to get s**t done.

2. D has long recognized that C++ exists and tries to be accommodating - with extern(C++) and C++ compatible COM classes. extern(C++) already does more than just adjust the name mangling.

3. There's significant demand for supporting C++ namespaces among people trying to migrate to D. There's more than just the people who post here. Currently, this is a barrier to adoption of D, and an unnecessary one.

4. I know I very much appreciate products that don't try and pretend they are the shiznit and nothing else exists. For example, Thunderbird Mail was able to import my old Outlook Express database perfectly, enabling me to completely abandon OE.

5. There's also work underway to better integrate with ObjectiveC.

In the light of that:

1. We cannot nicely support them all. But we don't have to. We can support the low hanging fruit.

2. C++ namespaces are very low hanging fruit, with a significant payoff. It's worthwhile.

3. C++ is special because a) we can support limited interoperability without much effort and b) a lot of people come to D from C++ and want to interoperate.

On 4/2/2014 3:07 PM, Walter Bright wrote:
> One downside of this proposal is that if we ever (perish the thought!) attempted
> to interface to C++ templates, this design would preclude that.

Yes, this seems to be a fatal flaw. Another design that has evolved from these discussions and my discussions with Andrei on it:

    extern (C++, namespace = A.B) { void foo(); void bar(); }
    extern (C++, namespace = C) void foo();

    bar();  // works
    A.B.bar(); // works
    foo(); // error: ambiguous
    C.foo();   // works

    alias C.foo foo;
    foo();  // works, calling C.foo()

I really think the namespace semantics should be attached to the extern(C++) rather than be a separate pragma. Having the namespace= thing means that namespace isn't a keyword, and provides a general mechanism where we can add language specific information as necessary.

On Saturday, 5 April 2014 at 20:47:29 UTC, Walter Bright wrote:
> On 4/2/2014 3:07 PM, Walter Bright wrote:
>> One downside of this proposal is that if we ever (perish the thought!) attempted
>> to interface to C++ templates, this design would preclude that.
>
> Yes, this seems to be a fatal flaw. Another design that has evolved from these discussions and my discussions with Andrei on it:
>
>     extern (C++, namespace = A.B) { void foo(); void bar(); }
>     extern (C++, namespace = C) void foo();
>
>     bar();  // works
>     A.B.bar(); // works
>     foo(); // error: ambiguous
>     C.foo();   // works
>
>     alias C.foo foo;
>     foo();  // works, calling C.foo()
>
> I really think the namespace semantics should be attached to the extern(C++) rather than be a separate pragma. Having the namespace= thing means that namespace isn't a keyword, and provides a general mechanism where we can add language specific information as necessary.

How could this common pattern look?
std::string
boost::fun(std::string arg)

alias cpp    = extern (C++, namespace = std);
alias boost = extern (C++, namespace = boost);

cpp.string
boost.fun(cpp.string arg)

?

On 4/5/2014 2:31 PM, Tove wrote:
> How could this common pattern look?
> std::string
> boost::fun(std::string arg)
>
> alias cpp    = extern (C++, namespace = std);
> alias boost = extern (C++, namespace = boost);
>
> cpp.string
> boost.fun(cpp.string arg)
>
> ?

extern (C++, namespace = std) {
    struct string { ... }
}

extern (C++, namespace = boost) {
    void fun(std.string arg);
}

On 2014-04-05 20:47:32 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 4/2/2014 3:07 PM, Walter Bright wrote:
>> One downside of this proposal is that if we ever (perish the thought!) attempted
>> to interface to C++ templates, this design would preclude that.
> 
> Yes, this seems to be a fatal flaw. Another design that has evolved from these discussions and my discussions with Andrei on it:
> 
>      extern (C++, namespace = A.B) { void foo(); void bar(); }
>      extern (C++, namespace = C) void foo();
> 
>      bar();  // works
>      A.B.bar(); // works
>      foo(); // error: ambiguous
>      C.foo();   // works
> 
>      alias C.foo foo;
>      foo();  // works, calling C.foo()
> 
> I really think the namespace semantics should be attached to the extern(C++) rather than be a separate pragma. Having the namespace= thing means that namespace isn't a keyword, and provides a general mechanism where we can add language specific information as necessary.

I like this idea. But... should this potentially useful thing really be restricted to extern C++ things? I've seen at least one attempt to create a namespace using what D currently offers [1], and frankly something like the above would make much more sense than a class no one can instantiate.

[1]: http://dlang.org/phobos/std_datetime.html#.Clock

Here's a suggestion:

	@namespace A.B { // can create two levels at once, yeah!
		void foo();
		void bar();
	}
	@namespace C {
		void foo();
	}

Make those C++ declarations, it does not look too foreign anymore:

	extern (C++) @namespace A.B {
		void foo();
		void bar();
	}
	extern (C++) @namespace C {
		void foo();
	}

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