Safe Cursors and Ranges

[Pillsy]

Jonathan M Davis Wrote:

> On Thursday, August 26, 2010 10:51:02 Andrei Alexandrescu
> wrote:
[...]
> > 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.

I really don't disagree. One of the reasons I'm suggesting that we
have a Tripod[1] concept to cover these three-legged operations is 
that I think that it's cohesive enough that fitting this functionality 
into a Range directly is unduly complicating. Having two concepts 
which each provide a reasonably orthogonal set of six basic 
operations is much less complicated than having one concept which
provides a dozen less orthogonal operations. 

[1] I actually think "Pivot" is the right name of the range+iterator-in-the-middle abstraction.

> 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.

Huh. I use it with some frequency when I program C++, and I hardly
regard myself as a C++ wizard. Sure, it can be pretty damn awkward,
but welcome to C++.
[...]
> 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. 

I think the lambda functions are a great example: they're a place
where C++98/03 doesn't provide *enough*, rather than providing 
too much. The library runs up against a fundamental limitation of 
the underlying language, rendering parts of it (like for_each) pretty 
useless.

There can be a severe cost to not providing enough.
[...]
> 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).

This is definitely agree with. Making something that legitimately 
does everything anyone could ever want is how you end up with
nightmares like Scheme's call-with-current-continuation, but letting
1 use case in 10 drop on the floor makes the cost/benefit ratio of
learning your library or language really dubious.
[...]
Cheers,
Pillsy