More complexity creep in Phobos

[Andrei Alexandrescu]

I started an alphabetical search through std modules, and as luck would 
have it I got as far as the first module: std/algorithm/comparison.d. In 
there, there's these overloads:

size_t levenshteinDistance(alias equals = (a,b) => a == b, Range1, Range2)
     (Range1 s, Range2 t)
if (isForwardRange!(Range1) && isForwardRange!(Range2));

size_t levenshteinDistance(alias equals = (a,b) => a == b, Range1, Range2)
     (auto ref Range1 s, auto ref Range2 t)
if (isConvertibleToString!Range1 || isConvertibleToString!Range2)

(similar for levenshteinDistanceAndPath)

What's with the second overload nonsense? The Levenshtein algorithm 
works on forward ranges. And that's about it, in a profound sense: 
Platonically what the algorithm needs is two forward ranges to operate. 
(We ought to be pretty proud of it, too: in all other languages I looked 
at, it's misimplemented to require random access.)

The second overload comes from a warped sense of DWIM: well if this type 
converts to a string, we commit to support that too. Really. How about a 
struct that converts to an array? Should we put in a pull request to 
that, too? Where do we even stop?

I hope there's not much more of this nonsense, because it all should be 
deprecated with fire.