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



--- Comment #10 from Dimitri Sabadie <dimitri.sabadie@gmail.com> 2012-11-04 04:11:05 PST ---
(In reply to comment #9)
> 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.

The difference is that no one expect D developpers — who know the phobos — want
to manipulate a range as return of a search function. An index would be okay
since it returns a logic value for a search concept, but seriously, why would
it return the range with all poped up values to find the object ? It’s clearly
weird, and D is the single langage to do such a thing. Also, wanting to
refactor all the world is clearly not a good idea. Sometimes, rewritting the
wheel to adapt it for a specific concept is faraway better than reusing a weird
code that makes the function weird. Moreover, any would be something like 3-4
lines of code… It’s really terrible. So you prefer to write it with just one
line and propose a weird interface. Clever.

-- 
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 #11 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-11-04 04:26:54 PST ---
C++'s find takes a pair of iterators indicating the beginning and ending of a range and returns an iterator to the element found - i.e. the new beginning of the range. D's ranges can be viewed as being the same as that pair of iterators. But unlike iterators, they always have a begin and end. So, rathering than just return the new begin (which it can't do, because that would be one iterator instead of the pair), D's find returns the new begin and the end together as a new range. What D is doing is the logical progression of what happens when you move from iterators to ranges.

You're free to not like it, but it works _very_ well, and it's very much in line with how C++ does things, only we're doing it with ranges rather than iterators, and the result is actually much more powerful than what C++ has, because ranges are far more powerful.

As for returning an index, that doesn't work for D any more than it works for C++. For anything which isn't random access, you'd have to iterate over the entire range again to get to that element. Iterators are _far_ more efficient than using indices. If you were to ask a linked list for its nth element, you'd have to iterate over the entire list up to that element to get to it, meaning that something like

for(size_t i = 0; i < list.size(); ++i)
    auto e = list.getIndex(i);

would actually end up iterating over the entire list multiple times in order to get to each element. Contrast that with iterators, which iterate only once

for(list::iterator iter; iter < list.end(); ++iter)
    auto e = *iter;

Ranges are just a further evolution of iterators, and the result is surprisingly flexible and powerful, especially when you start chaining function calls. One of the major rationales behind ranges is discussed here:

http://www.drdobbs.com/architecture-and-design/component-programming-in-d/240008321

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