Why does std.string use public imports?

[Andrej Mitrovic]

On 7/1/11, Jonathan M Davis <jmdavisProg at gmx.com> 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.