Selective and renamed imports

[Nick Sabalausky]

"Christian Kamm" <kamm-incasoftware at removethis.de> wrote in message 
news:j7eahc$30ph$1 at digitalmars.com...
> Hello fellow import-users,
>
> I've tried to get bug 314
> (http://d.puremagic.com/issues/show_bug.cgi?id=314) fixed for a very long
> time now. There seems to be no progress and I suspect that the reason for 
> it
> could be that Walter is unsure whether the import behavior I implemented 
> in
> https://github.com/D-Programming-Language/dmd/pull/190 is desirable.
>
> In this post I'll point out the controversy with selective imports and 
> hope
> it'll spark some discussion.
>
> First off, I think everyone agrees that this test case needs to start
> passing:
>
> base.d --
> int foo(int) { return 0; }
>
> first.d --
> import base : foo;
>
> second.d --
> import first;
> static assert(!is(typeof(foo)));
>
> It's the baseline for bug 314. No matter how the details are resolved, 
> this
> needs to work. It's the big "D doesn't even get imports right" hole that
> makes this bug the most voted for issue on bugzilla.
>
> 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.
>

Yes, what Christian suggests is what I would expect. Imports should just be 
imports, whether selective or otherwise. Actually merging symbols into the 
current module is the job of alias, and if that's the behavior I wanted, 
than that's what I would have used: alias. If *certain* imports (ie, 
selective) are invading alias's territory, I'd classify that as either a bug 
or a design error.