Shout out to D at cppcon, when talkign about ranges.

[Jonathan M Davis via Digitalmars-d]

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