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