Why does std.string use public imports?

[Jonathan M Davis]

On 2011-07-01 14:58, Andrej Mitrovic wrote:
> 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.

Well, for some functions, conflicts are going to be pretty much inevitable. 
And the number is only likely to go up as Phobos' size increases. Smart 
function naming reduces it, but sometimes the best name is the same name as 
one which already exists, and conflicts are going to happen. They won't 
normally be public imports like that, but they're going to happen.

- Jonathan M Davis