Selective and renamed imports

[Dmitry Olshansky]

On 16.10.2011 14:08, Christian Kamm wrote:
> 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, import != add a public alias from given module. Let them be 
consistent.
P.S. I'm looking forward to that patch eventually getting merged.

-- 
Dmitry Olshansky