Safe Cursors and Ranges

[Jonathan M Davis]

On Thursday, August 26, 2010 10:51:02 Andrei Alexandrescu wrote:
> On 8/26/10 9:18 PDT, dsimcha wrote:
> > I'm starting to think that the whole concept of ranges is starting to get
> > too complicated.  We're already seeing it with this moveFront() stuff
> > that's a special case to deal with structs that have expensive
> > postblits.  We need a healthy dose of "worse is better" to throw at
> > ranges.  IMHO generic code should solve 90% of the problem in a way
> > that's robust, not terribly hard to implement and easy to use and
> > understand.  Trying to solve 100% of the problem with generic code means
> > that your solution will be absurdly complicated in both interface and
> > implementation, and therefore will be a buggy POS that nobody can figure
> > out how to use.
> 
> [...]
> 
> > It's better to have ranges that can solve 90% of the problem for the most
> > competent 80% of programmers than ranges that can solve 100% of the
> > problem, but only for the 1% who are hardcore gurus.
> 
> I'm weary of this philosophy. I've seen a phenomenon happen time and
> again with myself and others: you hit a 10% case exactly when you (a)
> know what you want to do, (b) you know that the library could and should
> help you, and (c) you are working on a difficult enough problem to be
> wary of implementing it by hand.

I think that what it comes down to is that you need to be smart about what 
functionality that you do and don't include. David has an excellent point that 
when APIs become too complicated, they don't get used. For instance, I know 
_very_ few people who even _consider_ using C++'s algorithm library. It's just 
too hard to use. It has too many quirks (like how remove() works) and the lack 
of lambdas functions makes it incredibly painful to do simple things with it. 
Any library with much complexity is going to run into such issues, but they need 
to be minimized for a library to be properly useable. We can't afford to make 
ranges too complex. They need to be reasonably useable by your average 
programmer.

Any time that we need to add functionality to make them do more, we need to 
weigh the benefits and costs. If adding ability X makes it possible to do thing 
Y, but only a few people need to do thing Y, and adding feature X greatly 
increases the complexity, then it probably shouldn't be added. On the other 
hand, if adding feature X doesn't add much complexity and/or a lot of people 
need to do thing Y, then it would likely be a good thing to add feature X.

If we find something that a lot of people are trying to do and can't, then we 
need to really look at a reasonable way to make it possible. However, there are 
limits to what you can do without making Phobos' APIs unreasonably complex to 
understand and use. I do _not_ think that we should necessarily be hitting the 
100% case. The cost for that is likely too high. However, we probably should be 
going for more like the 98% or 99% case. (after all 90% indicates that 1 out of 
10 things that you try to do won't be feasible, and that's actually a lot, much 
as 90% sounds like a big number).

So, I do think that we should be making ranges (and the rest of Phobos) as 
powerful we reasonably can, but there _are_ limits to what they can reasonably 
do, and we should not necessarily try to make it so that they can do absolutely 
everything. And when we do make ranges more powerful, we need to strive to limit 
the increase to complexity as much as possible. Ultimately, ranges really should 
be powerful enough to do virtually everything that you would normally do with 
iterators (along with what they can do that iterators can't), but they should 
also be useable by the average programmer. Whatever we do needs to reasonably 
balance those goals. And I think that there is legitmate concern that ranges are 
risking becoming too complex.

- Jonathan M Davis