Hi Neil

'Critisms' is putting very strongly, hopefully it's more in the line of user feedback experience. Overall of course

the reality that I'm pushing it to breaking point is testament to it usefulness and overall cohesion.

So, in this instance it did not seem wise to me that the sliced adaptor makes use of iterator arithmetic, and

hence requires random access iterators, or makes use of the source range's end() as it does.

Characteristics of a superior solution would be to be as close as possible to perpetuating the range

classification of its source range, and to avoid use of the source range's end() until the consumer

gets there, hence fully supporting laziness.

I think this is largely achieved by the OvenToBoost implementation, which creates a new iterator type

using iterator facade or adaptor in the style of transform iterator, and builds a range type on top of that.

The implementation then counts increments, which is the lightest possible touch I think. It looks like

this approach would support slicing of unterminated ranges, such as read from stdin (I think).

Great to see you back on the case btw!

- Rob.

Rob it appears from your comment that you have have a number of design criticisms. Would you please make these in a more concrete fashion either on-list or however you feel most comfortable? I'd rather not lose the feedback, but the feedback (to paraphrase - I think the designs dodgy) has very limited utility. If there are considerations let's make them specific and consider superior alternatives.