On Wednesday, 7 October 2015 at 16:33:21 UTC, John Colvin wrote:
On Wednesday, 7 October 2015 at 14:59:28 UTC, Trass3r wrote:
On Tuesday, 6 October 2015 at 22:39:01 UTC, Ulrich Küttler
wrote:
Yes, this is an explanation. Thanks. So the argument being
C++ customs. Now that you mention it, this seems to be the
argument in Eric's D4128 paper, too.
I was hoping for a somewhat deeper reasoning. Out of
curiously, I am still trying to grasp all the implications.
Ranges are hard.
Another one is "odd number of iterators algorithms"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4128.html#appendix-3-d-ranges-and-algorithmic-complexity
D’s choice of algorithmic basis operations is inherently less
efficient than C++’s.
Hmm. That seems really contrived and/or missing the point. You
would never design a function like that for use with ranges,
but that doesn't mean you're any less able to efficiently find
word boundaries using ranges.
As I understand it, there are algorithms that inherently need 3
iterators to do whatever is they do, and the question of how to
deal with them has come up before in the newsgroup. I think that
it's pretty clear that such algorithms are relatively few in
number, but they do exist, and solving them with ranges does get
potentially awkward. Similarly, using iterators with containers
when you have to pass them to the container generally works
better than ranges do. We've had to add overloads to the
std.container types which take the results of the various take
functions in order to work around that problem. So, there are
clearly cases where ranges become awkward and iterators aren't.
On the other hand, when dealing with algorithms, ranges tend to
be far cleaner - especially when you need to chain them. And they
tend to form a better basis of how to think about algorithms
(even when dealing with iterators, you pretty much have to think
in terms of ranges on some level at least). And ranges handle
laziness far better than iterators do. So, I'm not the least bit
convinced that iterators are a better way to go (quite the
opposite), and I'm not convinced that trying to mix iterators and
ranges is at all a good idea. But I do think that it's clear that
using only ranges is not without its downsides, and since we're
the first folks to seriously use ranges heavily in a language or
standard library, we're bound to be making mistakes due to
inexperience. At this point, I would guess that trying to mix
iterators and ranges is just going to over-complicate things in
an already over-complicated language, but it may actually be a
big win for the C++ folks. We'll have to wait and see.
If we _were_ to look at doing something more than straight
ranges, we'd probably look more at something like Steven's
cursors than adding iterators, though I think that there's a
decent chance that that only really helps with containers (it's
been a while since I looked at what he did with cursors, and I
really don't remember the details), though for the most part, I
think that containers are the primary place where ranges tend to
get annoying. Algorithms where they're problematic do exist, but
they seem to be rare.
- Jonathan M Davis
