On 7/1/11, Jonathan M Davis <[email protected]> wrote: > On 2011-06-30 17:12, Jonathan M Davis wrote: >> On 2011-06-30 16:14, Andrej Mitrovic wrote: >> > I'm referring to these two in std.string: >> > public import std.algorithm : startsWith, endsWith, cmp, count; >> > public import std.array : join, split; >> > >> > Because whenever I try to use .count in my code: >> > >> > import std.stdio; >> > import std.string; >> > import std.utf; >> > >> > void main() >> > { >> > writeln("foo".count); >> > } >> > >> > std.utf.count conflicts with std.string's publicly imported >> > std.algorithm.count >> > >> > Can we avoid public imports in modules? The rise of conflicts in >> > Phobos is getting slightly annoying. >> >> I believe that they're there because the functions in question used to be >> in std.string but were generalized and moved to other modules. So, rather >> than immediately break code, they were publicly imported in std.string. >> They're scheduled for deprecation and will be removed once the deprecation >> process has completed. However, they shouldn't be causing conflicts. It's >> probably due to a bug related to explicit imports being seen as new >> functions in the module that they're imported into (I forget the bug >> number). Maybe using static imports with aliases would fix the problem. > > Actually, now that I look at it more closely, the problem that you're seeing > is fully expected and desired. It's complaining that std.string has a count > function and that std.utf has a count function and that it doesn't know > which > to use. That's exactly what's supposed to happen when two modules have > functions which conflict. std.string has had a count function for a long > time. > So, this is the behavior that you would have seen for a long time. > std.string's count has been generalized and moved to std.algorithm, so > you're > going to get the same conflict between std.algorithm.count and std.utf.count > - > which is expected. The public import is part of the deprecation and will go > away eventually. At that point, std.string and std.utf will no longer > conflict > for count, because std.string won't have a count function anymore. But > there's > no bug here. What you're seeing here is exactly what std.string and std.utf > have been doing for some time. It's a natural side effect of using the same > function name in multiple modules. Using the full module path for the > function > fixes the problem (though it doesn't work with the member function call > syntax > in that case). It's how the module system works and fully expected. > > - Jonathan M Davis >
When did I ever say it was a bug? I said it's annoying that there's conflicts due to public imports. If it's going away, good. I know algorithm has count, but I never imported that module, std.string imported it publicly so I got conflicts even though I was trying to avoid them.
