Selective and renamed imports

[Jesse Phillips]

On Sun, 16 Oct 2011 12:08:53 +0200, Christian Kamm wrote:

> Now, what's the problem? Overload resolution.
> 
> Currently, selectively importing a function or overload set also *merges
> it into the local module's overload set*. That has several problems. One
> is that changing an import to selective or back can change program
> behavior:
> 
> overloadproblem.d --
> import base; // : foo;
> long foo(long) { return 0; }
> static assert(is(typeof(foo(0)) == long));
> 
> This code will fail to compile when you change the import to a selective
> one.
> 
> The second problem is that, since the base.foo got integrated into the
> overloadproblem.foo overload set, modules importing 'overloadproblem'
> are no longer able to honor import visibility:
> 
> importer.d --
> import overloadproblem;
> static assert(is(typeof(foo(0)) == long));
> 
> This will fail even though base.foo was imported privately. To resolve
> foo(0) to long overloadproblem.foo(long), import visibility would have
> to be considered during overload resolution to skip int base.foo(int).
> That's something Walter doesn't want to do.
> 
> 
> These are the reasons why my pull request changes the selective import
> behavior to not merge overload sets. It makes 'import base : foo;' treat
> 'foo' exactly the same way as 'import base;' would have done; it does
> not matter whether an symbol was imported selectively or not. You can
> get the old behavior by using an explicit alias.
> 
> Does this work as you'd expect? Please write a short reply even if you
> just agree. I hope the feedback will convince Walter to give this
> serious consideration. You can also let me know that this is totally
> bananas, of course.
> 
> Regards,
> Christian

Yes, this sounds like what is supposed to happen, and addresses some 
questions that have come up on D.learn.