On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:
> Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.

The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength. Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.

When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++. My work is based on Boost.Range. I only posted here to clear up what appeared to me to be confusion about that.

\e

On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:
> On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:
>> Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.
>
> The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength. Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.

D's ranges and their use in D's standard library owe a _lot_ to C++ - especially to the STL. They just don't owe anything to Boost's ranges. They're two different paths from the same root.

> When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++. My work is based on Boost.Range.

It'll be interesting to see where that goes.

- Jonathan M Davis

On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:
> On Monday, 5 October 2015 at 21:57:31 UTC, Walter Bright wrote:
>> Yes, you can build debug iterators that know their limits, or iterators with back pointers to the range. This is not an inherent property of Boost ranges, does not appear in the Boost description of ranges (unless I missed it), and is a kludge. I do not agree that D ranges owe anything to that design.
>
> The design of the D ranges and algorithms owe quite a lot to C++, and I've heard Andrei say as much. Stepanov did the hard work of defining common algorithms in terms of iterators of different strength.

There is no denying that D owns a lot to C++. Then again D comes with great ideas of its own and success has many fathers.

> Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.
>
> When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.

What is your thinking here? Did you write it down somewhere? This would be very interesting.

> My work is based on Boost.Range. I only posted here to clear up what appeared to me to be confusion about that.
>
> \e

On Tuesday, 6 October 2015 at 06:52:13 UTC, Ulrich Kuettler wrote:
> On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:
>> Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.
>>
>> When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.
>
> What is your thinking here? Did you write it down somewhere? This would be very interesting.

Obviously, Eric would have to respond for us to know what his reasoning was, but I expect that it least part of it stems from the fact that C++ already uses iterators heavily. So, having a range-based solution that doesn't interact with iterators (like D has) doesn't fit in well with the existing code and paradigms. Even if you were to assume that D's approach is superior (which is debatable), that doesn't mean that it's a good fit for C++. D has the advantage of having considerably less baggage to deal with, so we have more freedom in the direction that we go. Whether we go in the right direction or not is another matter, but C++ has considerably more constraints than we have, so it's no surprise if we end up with different solutions.

- Jonathan M Davis

On 10/5/2015 7:31 PM, Eric Niebler wrote:
> The design of the D ranges and algorithms owe quite a lot to C++, and I've heard
> Andrei say as much.

D ranges owe plenty to C++ iterators and algorithms, no doubt. Boost ranges, I can't agree.

> Stepanov did the hard work of defining common algorithms in
> terms of iterators of different strength. Given that starting point, ranges of
> different strength are an "obvious" next step that many people thought up
> independently. D took it one way and C++ went another.

It seems obvious in retrospect, I agree. But looking at the early Boost ranges, they didn't take the obvious step :-)

> When designing my range library, I looked at all the prior art available to me
> including D ranges and decided D's path was not the right one for C++. My work
> is based on Boost.Range. I only posted here to clear up what appeared to me to
> be confusion about that.

On Tuesday, 6 October 2015 at 07:09:21 UTC, Jonathan M Davis wrote:
> On Tuesday, 6 October 2015 at 06:52:13 UTC, Ulrich Kuettler wrote:
>> On Tuesday, 6 October 2015 at 02:31:53 UTC, Eric Niebler wrote:
>>> Given that starting point, ranges of different strength are an "obvious" next step that many people thought up independently. D took it one way and C++ went another.
>>>
>>> When designing my range library, I looked at all the prior art available to me including D ranges and decided D's path was not the right one for C++.
>>
>> What is your thinking here? Did you write it down somewhere? This would be very interesting.
>
> Obviously, Eric would have to respond for us to know what his reasoning was, but I expect that it least part of it stems from the fact that C++ already uses iterators heavily. So, having a range-based solution that doesn't interact with iterators (like D has) doesn't fit in well with the existing code and paradigms. Even if you were to assume that D's approach is superior (which is debatable), that doesn't mean that it's a good fit for C++. D has the advantage of having considerably less baggage to deal with, so we have more freedom in the direction that we go. Whether we go in the right direction or not is another matter, but C++ has considerably more constraints than we have, so it's no surprise if we end up with different solutions.
>

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.

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.

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.

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

On Wednesday, 7 October 2015 at 17:13:45 UTC, Jonathan M Davis wrote:
> 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

Couldn't we define a TriRange or something for this?