www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6730] New: std.algorithm.splitter conflicts with std.array.splitter

reply d-bugmail puremagic.com writes:
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



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: -------
Sep 25 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6730


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



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: -------
Sep 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6730






 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: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6730




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: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6730


monarchdodra gmail.com changed:

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



*** 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: -------
Aug 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Oct 02 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6730






 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: -------
Oct 03 2013