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.
