Why does std.string use public imports?

[simendsjo]

On 01.07.2011 22:06, Jonathan M Davis 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

Isn't it expected that std.string contains a count method?

import std.stdio;
import std.string;
void main() {
     auto s = "à";
     writeln(s.length); // 2 - often you want the actual number of 
characters, not code points
     writeln(s.count()); // 1 - should a user need to import count from 
algorithm/utf to get this?
}