Safe Cursors and Ranges

[Andrei Alexandrescu]

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.

Two examples from recent history: A poster used std.algorithm for the 
_first_ (sic!) time, and found a fundamental limitation: std.algorithm 
doesn't work with immutable arrays. Second, Peter Alexander wanted to 
implement nextPermutation (a nontrivial algorithm in which you need all 
the help you can get) as his _first_ (sic again!) artifact of a new 
library, and hit the bidirectional range composition limitation.

I don't think we want to aim std.algorithm and others for a 90% thing. 
That's what Visual Basic did. We should aim for making it a 100% thing 
without losing the other costs from sight (something that I believe we 
have a good track record on).

In light of that, it's worth looking at optional functionality of the 
kind I described (allBefore etc.) would add power without aggravating 
everyone.

Also, regarding moveFront and friends, I think it's a good time to start 
the following discussion: do we want to support types with arbitrarily 
expensive copying, or could we simply require reference counting and 
copy-on-write for such types? Let's start a new thread about this!


Andrei