Specifying C++ symbols in C++ namespaces

[Walter Bright]

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.