For the mere mortals among us, who are struggling to keep up with the metaprogramming astronauts, am I right in thinking that you are lamenting the emphasis on 'bells and whistles' to support SIMD iterators, while the more fundamental aspects of iterator segmentation are being ignored?
That's how I've read the discussion. The previous thread seems to have trailed off into a space that more to do with particulars and little to do with the fundamental abstraction. On the topic of abstraction, I would say that Matt's solution seems to be the right approach -- from an iterator perspective. He claims that segmentation concepts is an orthogonal to the standard iterator concepts. I don't especially like the implementation, requiring an explicit specialization of segmented_iterator_traits. I see nothing preventing the segmented iterator class from defining those associated types and operations and allowing the traits class to use them by default. The solution seems to fit the GP pattern quite well. Specialize generic algorithms for orthogonal or refined concepts to get faster code for "free". I don't really know enough about Fusion to comment on the design, but on the surface it seems like an equivalent solution.
And in your last remark are you saying you fear that metaprogramming and the Boost MPL are monsters!?
My feeling on metaprogramming (and hence the MPL) is that it's a necessary evil for the style of generic programming going on here: necessary because it's the duct tape that holds generic libraries together, evil because it allows us to focus on really low-level details while doing some really clever programming. In case this may have read differently, I think that this style of generic programming is actually a good thing. Andrew