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
