Import conflict resoultion

[Dave]

Regan Heath wrote:

[lots of great stuff snipped for brevity]

>   import std.string std.string;

(forces FQN with the original module name)

> 
> FQN access is curently always present, but not required. However, with 
> solution #4 FQN access to the symbol is no longer
> ever required. It's presence results in code which can call the same 
> function in more than one way. This allows the code to
> be inconsistent for no gain (that I can imagine) therefore i think that 
> solution #4 should prevent FQN access to symbols.

I agree with all of your conclusions, with the caveat for compiler 
writers that the current alias functionality cannot be used internally 
to implement this given the above two requirements.

You can't:

alias foo foo;

and:

alias foo myfoo;

doesn't force myfoo to be used over 'foo'.

But I think it is all-around the best solution for the same rational given.

Given your rational and proposal, the _need_ for "specific symbol 
import" functionality will probably disappear too, keeping the language 
that much simpler to implement and less to learn and remember in order 
to maintain code.

import a.popular.db.lib dblib;
alias dblib.open dbopen;
alias dblib.close dbclose;

would be used instead of something like:

import a.popular.db.lib dblib
{
open dbopen;
close dbclose;
}

Not much difference in lines of code or effort to write or scan, the one 
advantage being that it would tend to keep aliased symbols close to the 
import (that's still a big advantage though, IMHO).