Symbol lookup rules and imports

[H. S. Teoh via Digitalmars-d]

On Fri, Dec 05, 2014 at 12:25:49AM +0100, Rainer Schuetze via Digitalmars-d wrote:
> 
> 
> On 02.12.2014 23:00, H. S. Teoh via Digitalmars-d wrote:
> >4) This isn't the end of the story. There's also this lovely bug:
> >
> >	https://issues.dlang.org/show_bug.cgi?id=1238
> >
> >which, as its number should tell you, has been around for a LONG
> >time.  Executive summary:
> >
> >	// mymod.d
> >	module mymod;
> >	private int impl;
> >
> >	// main.d
> >	module main;
> >	import mymod;
> >
> >	void impl() { ... }
> >
> >	void main() {
> >		impl(); // Error: main.impl conflicts with mymod.impl (WAT?)
> >	}
> 
> This compiles as expected. I guess you rather mean to import impl from
> two modules, one with a public impl, the other with a private impl. I
> don't think this belongs to the same set of issues as the other
> examples (though I agree private symbols from imports should not be
> considered in overload sets).

Sorry, poor example. Here's a tested example that produces an error:

	// mod.d
	module mod;
	private struct S {
	}

	// main.d
	module main;
	
	struct S {
		float x;
		int y;
	}
	
	void main() {
		import mod;
		S s;
	}

Compiler output:

	/tmp/test.d(10): Error: ScopeDsymbol main.__anonymous.__anonymous struct mod.S is private


> Here is another bad example of local import symbol hijacking:
[...]

My favorite variation on your example:

	import std.stdio;
	void say(string text) {
		import std.conv;
		writeln(text);
	}
	void main() {
		say("Hello world");
	}

prints an empty line. :-P  Commenting out the `import std.conv;` line
fixes the problem.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson