Bug 6730 – std.algorithm.splitter conflicts with std.array.splitter

A D2 program: import std.array, std.algorithm; void main() { auto r = splitter("hello how are you"); } DMD 2.056head gives: test.d(3): Error: std.algorithm.splitter!(string).splitter at ...\dmd2\src\phobos\std\algorithm.d(2184) conflicts with std.array.splitter!(immutable(char)).splitter at ...\dmd2\src\phobos\std\array.d(1088) Is this acceptable?

In general, I'd say yes. The fact that two functions in different modules can have the same name and conflict is fully expected and acceptable. The module system gives a number of ways to get around the problem. That's not an issue. However, in this case, what appears to be happening is that we have almost identical functions in two modules. The only difference between them is that the one in std.array will work with immutable strings, since it specifically types itself as taking an array, whereas std.algorithm's types itself as taking a range (though the range must be a string per the template constraint). If they did different things, that would be one thing, but I see no reason to have two identical functions. One of the two should be scheduled for deprecation.

(In reply to comment #1) > In general, I'd say yes. The fact that two functions in different modules can > have the same name and conflict is fully expected and acceptable. The module > system gives a number of ways to get around the problem. That's not an issue. > > However, in this case, what appears to be happening is that we have almost > identical functions in two modules. The only difference between them is that > the one in std.array will work with immutable strings, since it specifically > types itself as taking an array, whereas std.algorithm's types itself as taking > a range (though the range must be a string per the template constraint). If > they did different things, that would be one thing, but I see no reason to have > two identical functions. One of the two should be scheduled for deprecation. Assigned to self. Note that the one in std.algorithm is not documented, so anybody using it is probably doing it by mistake. My I outright remove it? Should I straight up give it deprecate it now? Do I have to go the full deprecation route?

I find it highly unlikely that they'd be using it by mistake, but since it's undocumented, it's not unreasonable to break code that's using it. However, it's probably still better to deprecate it first rather than outright remove it.

*** Issue 10383 has been marked as a duplicate of this issue. ***

Thing are really bad here as `std.range` which is often imported with `std.algorithm` publicly imports `std.array` so this will fail to compile: --- import std.algorithm, std.range; void main() { "".splitter(); } --- Too bad. Lets do something with this.

(In reply to comment #5) > Thing are really bad here as `std.range` which is often imported with > `std.algorithm` publicly imports `std.array` so this will fail to compile: > --- > import std.algorithm, std.range; > > void main() > { "".splitter(); } > --- > > Too bad. Lets do something with this. https://github.com/D-Programming-Language/phobos/pull/1502/files#diff-ff74a46362b5953e8c88120e2490f839R2824 I think a "short" deprecation plan (eg: 1 release) is called for here.

Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/06352bc88fc2a062ca25ef445c5852354fd502c8 Fix Issue 6730 https://github.com/D-Programming-Language/phobos/commit/72a1c4dbe451ddd5b9521c30047e7571266113cc Merge pull request #1823 from andralex/6730 Fix Issue 6730

*** Issue 11701 has been marked as a duplicate of this issue. ***