http://d.puremagic.com/issues/show_bug.cgi?id=8946

           Summary: « any » function does not what it should do
           Product: D
           Version: future
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: dimitri.sabadie@gmail.com


--- Comment #0 from Dimitri Sabadie <dimitri.sabadie@gmail.com> 2012-11-02 11:07:46 PDT ---
The any function calls find, which is really weird implemented because it returns a subrange, doing (re)allocation(s) on the fly. I think it’s way too much for just applying a predicate on a range. That’s why I have rewritten any as it would be (a simple loop and apply the predicate), and I’d propose a patch here for the std one.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946


Dmitry Olshansky <dmitry.olsh@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dmitry.olsh@gmail.com
         Resolution|                            |INVALID


--- Comment #1 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-03 07:18:01 PDT ---
Ever heard of slicing an array in D?

Check this out: http://dlang.org/d-array-article.html

Dig down in std.algotrithm.find and you'll find out that it's lazy iterates a forward range. Thus like the most of std.algorithm functions it DOESN'T allocate. In case of array it just returns a slice of original array.

So this report is invalid.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946



--- Comment #2 from Dimitri Sabadie <dimitri.sabadie@gmail.com> 2012-11-03 14:09:28 PDT ---
(In reply to comment #1)
> Ever heard of slicing an array in D?
> 
> Check this out: http://dlang.org/d-array-article.html
> 
> Dig down in std.algotrithm.find and you'll find out that it's lazy iterates a forward range. Thus like the most of std.algorithm functions it DOESN'T allocate. In case of array it just returns a slice of original array.
> 
> So this report is invalid.

Ok, my argument wasn’t worth it I agree. But, why any would use such a function where a simple loop and a test will do it? It’s the same argument for not to use countUntil and check if the index is invalid, it consumes more memory that we want. any does things we don’t want to IMHO.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946



--- Comment #3 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-03 14:18:25 PDT ---
> Ok, my argument wasn’t worth it I agree. But, why any would use such a function
where a simple loop and a test will do it?

Because find is a simple loop? To not duplicate code? If you have liner search then it's obvious (for me) to reuse it for exactly the same task. any basically gives you a bit less then find/countUntill (bool vs pointer-index) by doing the same amount of work.

> it consumes more memory that we want. any does things we don’t want to IMHO.

Simply not true. I'm not sure where this 'memory' argument comes from at all. In fact it saves some code space by not duplicating the same code over again. At best this could be an enhancement request (or better yet - a pull request) if there is a soild proof that the resulting code is measurably _faster_.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946



--- Comment #4 from Dimitri Sabadie <dimitri.sabadie@gmail.com> 2012-11-03 14:35:35 PDT ---
(In reply to comment #3)
> > Ok, my argument wasn’t worth it I agree. But, why any would use such a function
> where a simple loop and a test will do it?
> 
> Because find is a simple loop? To not duplicate code? If you have liner search then it's obvious (for me) to reuse it for exactly the same task. any basically gives you a bit less then find/countUntill (bool vs pointer-index) by doing the same amount of work.
> 
> > it consumes more memory that we want. any does things we don’t want to IMHO.
> 
> Simply not true. I'm not sure where this 'memory' argument comes from at all. In fact it saves some code space by not duplicating the same code over again. At best this could be an enhancement request (or better yet - a pull request) if there is a soild proof that the resulting code is measurably _faster_.

There’s a popFront() function, so why would it be the correct way to search?
Reusing a « linear search » code is not a point here because we want to _find_
something. countUntil gives us the position of an element, find should give
whether the element is or not in a range. It returns a range: why ? It’s
clearly implementation-related, and we don’t care about that detail. I’ll
propose a pull request because the simple fact there’s « find » and « any » is
not good.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946


timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch


--- Comment #5 from timon.gehr@gmx.ch 2012-11-03 14:47:42 PDT ---
(In reply to comment #4)
> ...
> There’s a popFront() function, so why would it be the correct way to search?
> Reusing a « linear search » code is not a point here because we want to _find_
> something. countUntil gives us the position of an element, find should give
> whether the element is or not in a range.

Well, no.

> It returns a range: why ?
> ...

Because that is its specification. What is the issue?

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946



--- Comment #6 from Dimitri Sabadie <dimitri.sabadie@gmail.com> 2012-11-03 16:45:23 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > ...
> > There’s a popFront() function, so why would it be the correct way to search?
> > Reusing a « linear search » code is not a point here because we want to _find_
> > something. countUntil gives us the position of an element, find should give
> > whether the element is or not in a range.
> 
> Well, no.
> 
> > It returns a range: why ?
> > ...
> 
> Because that is its specification. What is the issue?

The issue is: a function that is designed to « search » for something is excepted to return a boolean, not top popFront() shit and returns the result range…

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #7 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-11-03 16:58:47 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > ...
> > > There’s a popFront() function, so why would it be the correct way to search?
> > > Reusing a « linear search » code is not a point here because we want to _find_
> > > something. countUntil gives us the position of an element, find should give
> > > whether the element is or not in a range.
> > 
> > Well, no.
> > 
> > > It returns a range: why ?
> > > ...
> > 
> > Because that is its specification. What is the issue?
> 
> The issue is: a function that is designed to « search » for something is excepted to return a boolean, not top popFront() shit and returns the result range…

Then use canFind.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946



--- Comment #8 from timon.gehr@gmx.ch 2012-11-03 17:38:29 PDT ---
(In reply to comment #6)
> ...
> 
> The issue is: a function that is designed to « search » for something is excepted to return a boolean, not top popFront() [...] and returns the result range…

Maybe the expectation is flawed? eg. see www.google.com. The service called 'search' delivers more information than just a boolean.

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

http://d.puremagic.com/issues/show_bug.cgi?id=8946


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

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


--- Comment #9 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-11-03 18:12:26 PDT ---
> Then use canFind.

canFind does exactly the same thing.

The _only_ difference between calling find and checking whether the result was empty rather than duplicating find's implementation inside of canFind or any is the fact that a range is returned, and since that range is bound to be a relatively small type (almost always either an array or a struct with just a handful of member variables), the cost of that return is generally minimal, and there's a halfway decent chance that a move was involved rather than a copy, making it that much more efficient.

If there's a measurable difference in efficiency between calling find (and checking for empty) and reimplementing find inside of canFind or any, then maybe we'll look at making it so that canFind and any don't call find. But the overhead of that return is so small (especially in comparison to the algorithm itself), that I'd be surprised if that ever happened.

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