More complexity creep in Phobos

[Seb]

On Thursday, 28 March 2019 at 02:17:35 UTC, Andrei Alexandrescu 
wrote:
> 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?

See https://github.com/dlang/phobos/pull/3770 for the historical 
reason.

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

Then we would have to deprecate more than half of Phobos, because 
a lot of similar cruft got aggregated over the last ten years. 
Many of these crufts can't be as easily deprecated as this 
example...