Range proposals from Eric Niebler

[H. S. Teoh]

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