On Thursday, 11 July 2013 at 20:15:52 UTC, Namespace wrote:
The whole situation looks strange. If you can change both
files, than it is unclear what made you to write such
inconsistent code. If you can change only one of them, then it
should be adjusted to another (meaning importing external file
and using that enum instead of trying to define different type
and passing it).
Besides the problem of changing existing API:
If you change only one of those modules and use the enum from
the other file, every user have to look into the file which
declares the enum, to see which member the enum has.
This argument can be applied to virtually any peice of code of
any language which has import or #include.
This is almost same as direct cast in #2. Instead of making
test2() accept B or (u)int consider making it static void
test2 (MyClass.A a) and wipe out enum B entirely.
That's the problem I tried to describe above.
If you have those two modules as in my example code, the one
file without the enum depends on the one with the enum. Isn't
that a bad situation?
Any file importing map depens on std.algorithm. Isn't that a bad
situation?
A possible solution would be to change one of those functions
which accepts different enums, that it accept an uint - nothing
else is an enum (in this case).
Well if you consider that this is a best option nothing stops you
from doing this. In such case you can't mark functions as @safe
and may run into bugs when some integer value placed into enum
does not fit into allowed values. This problem is tackled by
final switches. By the way, in your case base type is int, not
uint.