Type: Vec: Change iterators to not create new collection during iteration

[leighmcculloch]

Type: Vec: Change iterators to not create new collection during iteration

[leighmcculloch]

I'm inclined to implement this not by changing the iterator in isolation, but changing the Vec so that a Vec is a handle plus a start and an end, so that repeatedly slicing a Vec makes no interactions with the host.

[jonjove]

I was just reviewing the documentation for im_rc in a different context. It occurred to me that we should be very careful to make sure the SDK interface we provide uses im_rc efficiently. For example, I am accustomed to Vec::get being O(1) but this is not true for im_rc::Vector::get which is O(log n). In fact, every data access operation is O(log n). Furthermore, the documentation for im_rc::vector::Iter and im_rc::vector::Focus emphasize that using a Focus can produce an order of magnitude speed-up in certain repeated look-up situations.

Given the above, should we expose im_rc::vector::Iter as a first-class host object? What about for im_rc::vector::Focus? It feels weird to me to expose this level of implementation detail, but at the same time I feel like we should provide tools for people to use system resources efficiently.

[leighmcculloch]

I think leaking idiosyncrasies of the im_rc::Vector come at a cost that has to be measured. i.e. What contracts will this impact, and by how much.

Digging into it though, would the changes you're suggesting – exposing Iter and Focus – be things the SDK consumes, or that users consume? If these are things the SDK consumes it's not so bad, but once we start pushing im_rc qualities to users we've bound the way their code works to it which would probably make it difficult for us to make changes to vector in the future. Or worse, we are bound to im_rc's implementation that could change.