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
