std.string and std.algorithm: what to do?

[dsimcha]

== Quote from Michiel Helvensteijn (m.helvensteijn.remove at gmail.com)'s article
> Michiel Helvensteijn wrote:
> > Your std.string.find() may carry the `algorithm' tag and the `string' tag.
> > So perhaps if both (or either?) of those tags are imported into a project,
> > the function would become available.
> Hm.. I suppose a project could import any Boolean combination of tags:
> import algorithm & string;
> import algorithm | string;
> import algorithm & !string;
> And if modules were gone, I suppose you'd want to tag all your
> standard-library functions with `std' as well.
> A bit too radical a change, I suppose. But I believe I will think about this
> some more. What do you think?

This seems like overkill.  Module/package/import/whatever management should not
require a Ph.D. in Boolean logic.  It should be dead simple (i.e. like the current
system is, esp. after 314 gets fixed) and allow people to get on with solving real
problems.  Yes, namespace pollution is annoying, but so is a ridiculously
fine-grained import system.  After all, the whole point of a module system is to
avoid namespace pollution.  Otherwise, it would make sense to just import every
darn module in every import path implicitly.  Sometimes, when people get
ridiculously crazy with hierarchical import structure and stuff, I feel like just
having a more polluted namespace is the lesser of two evils, especially in D,
where naming collision resolution is well-defined and sane.