Why does std.string use public imports?

[Jonathan M Davis]

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.

- Jonathan M Davis