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