extern(C++, NS)

[Jonathan M Davis via Digitalmars-d]

On Sunday, 29 November 2015 at 10:58:48 UTC, Manu wrote:
> On 29 November 2015 at 20:17, Iain Buclaw via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>> I think your idea with aliases was just wishful thinking, 
>> aliases themselves never worked like that.
>
> I thought aliases did produce a symbol in the scope they are 
> declared?
> Or do you mean with the private thing? Yeah...
> Aliases are often used to sort out these sorts of 
> scope/namespacing
> issues, I've seen it come up lots of times.

Aliases usually seem to work a lot like copy-pasting. If you do 
something like

alias New = Orig;

then everywhere that New is used in the code, it's effectively 
replaced with Orig, and you never even see it in any error 
messages. It's pretty much just for the programmer's benefit - 
e.g. avoiding having to type out the entire import path for a 
symbol over and over:

alias foo = some.pkg.somewhere.foo;

But there's still really only one symbol that the compiler is 
dealing with. It's kind of like how the C/C++ compiler never 
really sees macros, though it's more controlled than that. For 
instance, try compiling this code on a 32-bit system:

long val;
size_t i = val;

You'll get an error message complaining about trying to convert a 
long to a uint, just like if the code looked like

long val;
uint i = val;

The only places that I can think of where aliases don't act quite 
like this are when they're not used to replace one symbol with 
another - e.g. with alias this or with using alias to bring a 
base class overload into the scope of a derived class.

- Jonathan M Davis