D1: Overloading across modules

Nick Sabalausky a at a.a
Tue Mar 23 11:19:03 PDT 2010

"Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
news:hoa5v4$1bai$1 at digitalmars.com...
> Nick Sabalausky wrote:
>> In D1, is there any reason I should be getting an error on this?:
>> // module A:
>> enum FooA { fooA };
>> void bar(FooA x) {}
>> // module B:
>> import A;
>> enum FooB { fooB };
> alias A.bar bar;

Hmm, unfortunately (I just realized) my exact case is more like this:

// module A:
enum FooA { fooA };
void bar(FooA x) {}

// module B:
import A;
enum FooB { fooB };
void bar(FooB x) {}

// module C:
import A;
import B;
bar(FooB.fooB); // Error: A.bar conflicts with B.bar

Turns out that putting the alias in module B doesn't fix the problem, I have 
to put aliases to both "bar"s in module C.

>> void bar(FooB x) {}
>> bar(FooB.fooB); // Error: A.bar conflicts with B.bar
>> 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?
> The compiler assumes that, unless you specifically tell it otherwise,
> symbols pulled in from another module conflict with local ones.

I *really* hope that's changed in D2 (is it?), because that's completely 
breaking a utility I have. Specifically, I have a CTFE function "genEnum" 
that generates code (to be mixed in) which creates an enum along with an 
enumToString function (I realize Phobos2 has something similar to that, but 
Phobos1/Tango don't). The library that this is in also actually uses 
"genEnum", so any client code (or any other part of the same library) that 
wants to make use of genEnum has to jump through that alias contortion 
anywhere an enumToString is actually used.

I could change it to "{name of enum}ToString", but I'd really rather not 
have to do it that way (although I am doing it that way for the 
"stringToEnum" function since I obviously can't overload on return type). I 
was starting to think maybe I could try doing a function template like 
"enumToString!(enumTypeHere)(enumTypeHere.foo);", (which would perhaps be a 
better solution anyway) but without D2's template constraints I'm not sure 
how I'd be able to pull that off.

More information about the Digitalmars-d-learn mailing list