Selective and renamed imports

Christian Kamm kamm-incasoftware at removethis.de
Sun Oct 16 03:08:53 PDT 2011


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.

Regards,
Christian



More information about the Digitalmars-d mailing list