Thread overview
[Issue 6730] New: std.algorithm.splitter conflicts with std.array.splitter
Sep 25, 2011
Jonathan M Davis
Oct 23, 2012
Jonathan M Davis
Oct 03, 2013
Denis Shelomovskij
September 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6730

           Summary: std.algorithm.splitter conflicts with
                    std.array.splitter
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: enhancement
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: bearophile_hugs@eml.cc


--- Comment #0 from bearophile_hugs@eml.cc 2011-09-25 11:11:06 PDT ---
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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
September 25, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6730


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-09-25 14:19:59 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 23, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6730


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |monarchdodra@gmail.com
         AssignedTo|nobody@puremagic.com        |monarchdodra@gmail.com


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 23, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6730



--- Comment #2 from monarchdodra@gmail.com 2012-10-22 23:09:27 PDT ---
(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?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 23, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=6730



--- Comment #3 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-22 23:16:16 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
August 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6730


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmitry.olsh@gmail.com


--- Comment #4 from monarchdodra@gmail.com 2013-08-22 06:37:21 PDT ---
*** Issue 10383 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 03, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6730


Denis Shelomovskij <verylonglogin.reg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg@gmail.com
           Severity|enhancement                 |normal


--- Comment #5 from Denis Shelomovskij <verylonglogin.reg@gmail.com> 2013-10-03 10:46:09 MSD ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 03, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=6730



--- Comment #6 from monarchdodra@gmail.com 2013-10-03 00:24:49 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------