"BCS" <n...@anon.com> wrote in message
news:a6268ff119c68cc98a14e065...@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.
