Eric Niebler did a very interesting discussion targeting Range proposals for C++17.

I think it would be great inspiration for future improvements on D ranges:

The shortcomings of classical C++ (begin, end) ranges: http://ericniebler.com/2014/02/16/delimited-ranges/

The shortcomings of infinite ranges represented by (begin, end) ranges: http://ericniebler.com/2014/02/18/infinite-ranges/

Fixing ranges by allowing begin type to be different from end type, allowing Sentinel Ranges: http://ericniebler.com/2014/02/21/introducing-iterables/

Making this new Range (called by the author as Iterable) capable of dealing with infinite ranges: http://ericniebler.com/2014/02/27/ranges-infinity-and-beyond/

How this discussion touches D ranges design decisions?

On Thursday, 27 February 2014 at 14:46:25 UTC, Alessandro Stamatto wrote:
> Eric Niebler did a very interesting discussion targeting Range proposals for C++17.
>
> I think it would be great inspiration for future improvements on D ranges:
>
> The shortcomings of classical C++ (begin, end) ranges: http://ericniebler.com/2014/02/16/delimited-ranges/
>
> The shortcomings of infinite ranges represented by (begin, end) ranges: http://ericniebler.com/2014/02/18/infinite-ranges/
>
> Fixing ranges by allowing begin type to be different from end type, allowing Sentinel Ranges: http://ericniebler.com/2014/02/21/introducing-iterables/
>
> Making this new Range (called by the author as Iterable) capable of dealing with infinite ranges: http://ericniebler.com/2014/02/27/ranges-infinity-and-beyond/
>
> How this discussion touches D ranges design decisions?

Reddit discussions on these are interesting too. Eric talks about why he doesn't like D's ranges a bit.

http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_delimited_ranges/
http://www.reddit.com/r/cpp/comments/1yc03d/range_concepts_part_2_of_4_infinite_ranges/
http://www.reddit.com/r/cpp/comments/1yk89k/range_concepts_part_3_of_4_introducing_iterables/
http://www.reddit.com/r/cpp/comments/1z37m9/range_concepts_part_4_of_4_to_infinity_and_beyond/ (no comments yet, just posted)

Brad Anderson:

> Reddit discussions on these are interesting too. Eric talks about why he doesn't like D's ranges a bit.

What are the downsides of D ranges he sees?

Bye,
bearophile

On Friday, 28 February 2014 at 00:43:57 UTC, bearophile wrote:
> Brad Anderson:
>
>> Reddit discussions on these are interesting too. Eric talks about why he doesn't like D's ranges a bit.
>
> What are the downsides of D ranges he sees?
>

Here's what he wrote:

http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_delimited_ranges/cfhvl65

On Thu, Feb 27, 2014 at 4:55 PM, Brad Anderson <eco@gnuk.net> wrote:

> On Friday, 28 February 2014 at 00:43:57 UTC, bearophile wrote:
>
>> Brad Anderson:
>>
>>  Reddit discussions on these are interesting too. Eric talks about why he
>>> doesn't like D's ranges a bit.
>>>
>>
>> What are the downsides of D ranges he sees?
>>
>>
> Here's what he wrote:
>
> http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_ delimited_ranges/cfhvl65



I remember we were discussing this last year:

http://forum.dlang.org/thread/kd2qok$16e6$1@digitalmars.com [The rfind challenge]

Not sure what came out concretely.

On 2/27/2014 4:55 PM, Brad Anderson wrote:
> On Friday, 28 February 2014 at 00:43:57 UTC, bearophile wrote:
>> Brad Anderson:
>>
>>> Reddit discussions on these are interesting too. Eric talks about why he
>>> doesn't like D's ranges a bit.
>>
>> What are the downsides of D ranges he sees?
>>
>
> Here's what he wrote:
>
> http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_delimited_ranges/cfhvl65
>
>

Note that Andrei has added a reply to that.

On Friday, 28 February 2014 at 02:04:10 UTC, Walter Bright wrote:
> On 2/27/2014 4:55 PM, Brad Anderson wrote:
>> On Friday, 28 February 2014 at 00:43:57 UTC, bearophile wrote:
>>> Brad Anderson:
>>>
>>>> Reddit discussions on these are interesting too. Eric talks about why he
>>>> doesn't like D's ranges a bit.
>>>
>>> What are the downsides of D ranges he sees?
>>>
>>
>> Here's what he wrote:
>>
>> http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_delimited_ranges/cfhvl65
>>
>>
>
> Note that Andrei has added a reply to that.

tl;dr:

Eric: I don't like D ranges because there is no notion of position, so e.g. find has to return a range.

Andrei: Position may be nice to have, but we can get by without it, and having fewer concepts is itself a benefit.

On Fri, Feb 28, 2014 at 08:26:42PM +0000, Peter Alexander wrote:
> On Friday, 28 February 2014 at 02:04:10 UTC, Walter Bright wrote:
> >On 2/27/2014 4:55 PM, Brad Anderson wrote:
> >>On Friday, 28 February 2014 at 00:43:57 UTC, bearophile wrote:
> >>>Brad Anderson:
> >>>
> >>>>Reddit discussions on these are interesting too. Eric talks about why he doesn't like D's ranges a bit.
> >>>
> >>>What are the downsides of D ranges he sees?
> >>>
> >>
> >>Here's what he wrote:
> >>
> >>http://www.reddit.com/r/cpp/comments/1y60bk/range_concepts_part_1_of_4_delimited_ranges/cfhvl65
> >>
> >>
> >
> >Note that Andrei has added a reply to that.
> 
> tl;dr:
> 
> Eric: I don't like D ranges because there is no notion of position, so e.g. find has to return a range.
> 
> Andrei: Position may be nice to have, but we can get by without it, and having fewer concepts is itself a benefit.

My $0.02 worth:

We can philosophize all day about whether the find operation is inherently positional, or inherently range-based, but the real test is when the rubber hits the road.

Having written a fair amount of C++ code before, I think I can say fairly that position-based code is more complex, requires more fiddling with low-level details, and generally more unwieldy than range-based code. It's more powerful, no doubt -- there are things you can do with position-based code that you can't do with ranges, or can only do so with difficulty. But it's more fiddly, and requires painstaking attention to details for everyday, mundane tasks.

Range-based code does have its limitations, as Eric takes great pains to point out, but that's kinda missing the point, which is that range-based code makes everyday tasks easier to manage -- you get more things done for the same amount of effort. Everyday, mundane tasks are easier to write -- you don't have to constantly fret over details like off-by-1 errors, for example. Since it's rare that a programmer spends most of his time writing novel algorithms or cleverly complex code that requires that kind of low-level micromanagement, this is a net win IMO.

And when you do need to fiddle with positions (which is generally what happens when you're trying to do something clever with arrays), there's always countUntil() that returns, basically, what amounts to an index to the found element. That, with some clever combination of takeN, basically gives you almost the same power of position-based code with no additional library support needed. Or you could just write low-level code specific to what you're trying to do -- since most clever code is case-specific anyway.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL