Re: [PATCH/RFC v2 0/16] Introduce index file format version 5

> The current code that access nth entry from the index->cache[nth]
> would need to be updated to use an accessor function, whether the
> "nth" comes from index_name_pos() or from the for-loop that iterates
> over the entire index.  For the latter, you would need to give the
> users a function that returns a cursor into the in-core index to
> allow iterating over it.
>
> When you use an in-core representation that is not a flat array, the
> type of "nth", which is essentially a cursor, may have to change to
> something that is richer than a simple integer, in order to give the
> implementation of the in-core index a more efficient way to access
> the entry than traversing the leaves of the tree depth first, and
> you would need to update index_name_pos() to return such a "cursor".
> That design and development cost is part of updating the in-core
> data structure. In the end result, the runtime cost to manipulate an
> index entry that the cursor refers to should be minimum, as that
> would be the cost paid by all the users of the API anyway, even if
> we _were_ starting from an ideal world where there weren't any flat
> in-core index in the first place.