D1: Overloading across modules

[Nick Sabalausky]

"BCS" <none at anon.com> wrote in message 
news:a6268ff119c68cc98a14e065cd6 at news.digitalmars.com...
> Hello Nick,
>
>> Is overloading across modules not allowed? Is overloading on two
>> different enum types not allowed? Is it a DMD bug? Or does this all
>> work fine and I probably just have some other problem elsewhere?
>
> IIRC, this is done so that importing a module will never alter what 
> function a call binds to. By forcing an error, the program gets a prompt 
> to deal with it.
>

But isn't it going a lot farther than it needs to? I mean, if you have a 
function call "bar(e)" where "e" is of type "SomeEnum", then what other 
function "X bar( /+whatever+/ )" could possibly be made that would hijack 
the call without violating the ordinary intra-module overloading rules that 
already exist? I'm not aware of anything that can be implicitly converted to 
an enum.

Instead of having a rule "two functions from different modules conflict if 
they have the same name", shouldn't it really be "two functions from 
different modules conflict if they have the same name *and* implicit 
conversion rules make it possible for a call to one to be hijacked by the 
other"?

I'd also like to know, does all this still apply to D2 as well? Or has it 
been fixed there?
....
Oh shit....I just realized, thanks to that obnoxious "Enums are implicity 
convertable to their base type" rule (A rule which I already hate for 
blatantly breaking strong-typing), one can do this:

// Module Foo:
enum Foo { foo }

// module A:
import Foo;
void bar(Foo x){}

// module B version 1:
import Foo;
void bar(int x){}
bar(Foo.foo); // Stupid crap that should never be allowed in the first place

// module B version 2:
import Foo;
import A; // <- This line added
void bar(int x){}
bar(Foo.foo); // Now that conflict error *cough* "helps".

I think I'm going to merge this discussion with bearophile's "Enum equality 
test" and bring it over to the "digitalmars.D" ng.